Hi,
I´ve got a weird Issue updating my OPNSense Backup Appliance. I Use Version 20.1.7 and would like to upgrade.
When I Hit "Click to check for updates" I get the response "Timeout while connecting to the selected mirror".
What really strange is, the Master-Appliance is able to fetch updates.
The configuration of the two appliances is identical. I even cloned the Master-VM and reconfigured the clone to be the backup-VM, to be sure.
Same Networks, same Gateways (different IP´s ;-) ) and so on.
A ping to external (for example google.com) is possible.
When I try to connect to external (from console) with a tcp-connection (for example ftp / http) I get the response "unable to connect to remote host".
Both systems are behind a sophos UTM firewall where the same rules apply to both systems.
Packets from the master-vm arrive at the UTM. Packets from the backup-appliance do not arrive at the UTM.
This is the fw-log output from the backup-appliance.
LANInternal <- [timestamp] source is LAN-Address destination is target-address prot is tcp label is "let out anything from firewall host itsel (force gw)
I read in different forum-topics that several users seem to have the same problem... - but I found no solution...
Can you try this on the broken machine and paste the output here?
# pkg -d update -f
Beware of subtleties with defunct IPv6 which is probably hard to spot when DNS names are printed for connection.
Cheers,
Franco
Hi Franco, thanks for your reply!
here´s the output:
root@OPNsense02:~ # pkg -d update -f
DBG(1)[65636]> pkg initialized
Updating OPNsense repository catalogue...
DBG(1)[65636]> PkgRepo: verifying update for OPNsense
DBG(1)[65636]> PkgRepo: need forced update of OPNsense
DBG(1)[65636]> Pkgrepo, begin update of '/var/db/pkg/repo-OPNsense.sqlite'
DBG(1)[65636]> Fetch: fetching from: https://pkg.opnsense.org/FreeBSD:11:amd64/20.1/latest/meta.txz with opts "i"
DBG(1)[65636]> Fetch: fetching from: https://pkg.opnsense.org/FreeBSD:11:amd64/20.1/latest/meta.txz with opts "i"
DBG(1)[65636]> Fetch: fetching from: https://pkg.opnsense.org/FreeBSD:11:amd64/20.1/latest/meta.txz with opts "i"
pkg: https://pkg.opnsense.org/FreeBSD:11:amd64/20.1/latest/meta.txz: No route to host
repository OPNsense has no meta file, using default settings
DBG(1)[65636]> Fetch: fetching from: https://pkg.opnsense.org/FreeBSD:11:amd64/20.1/latest/packagesite.txz with opts "i"
DBG(1)[65636]> Fetch: fetching from: https://pkg.opnsense.org/FreeBSD:11:amd64/20.1/latest/packagesite.txz with opts "i"
DBG(1)[65636]> Fetch: fetching from: https://pkg.opnsense.org/FreeBSD:11:amd64/20.1/latest/packagesite.txz with opts "i"
pkg: https://pkg.opnsense.org/FreeBSD:11:amd64/20.1/latest/packagesite.txz: No route to host
Unable to update repository OPNsense
Error updating repositories!
Here the result of a ping to pkg.opnsense.org:
root@OPNsense02:~ # ping pkg.opnsense.org
PING pkg.opnsense.org (89.149.211.205): 56 data bytes
64 bytes from 89.149.211.205: icmp_seq=0 ttl=58 time=7.562 ms
64 bytes from 89.149.211.205: icmp_seq=1 ttl=58 time=7.574 ms
even when I use IPv4-Address for a https request for example i get this:
root@OPNsense02:~ # curl https://89.149.211.205/FreeBSD:11:amd64/20.1/latest/meta.txz
curl: (28) Failed to connect to 89.149.211.205 port 443: Operation timed out
So I think there must be something wrong on the TCP-Layer. - Layer 3 is working (Ping).
I would say a firewall-rule blocks the traffic, but the rules are the same on master and backup - synced.
When I do a TCP traceroute to the ip-address on the master I get this:
root@OPNsense01:~ # traceroute -P tcp 89.149.211.205
traceroute to 89.149.211.205 (89.149.211.205), 64 hops max, 40 byte packets
1 utm320-1 (xxx) 0.420 ms 0.438 ms 0.214 ms
2 xxx.de (xxx) 5.098 ms 5.345 ms 4.903 ms
3 xxx (xxx) 4.464 ms 4.392 ms 4.536 ms
4 et-1-0-0.bb04.ams-01.leaseweb.net (80.249.209.215) 7.459 ms 7.549 ms 9.662 ms
5 be-104.br02.ams-01.nl.leaseweb.net (31.31.38.143) 11.371 ms 8.381 ms 7.948 ms
6 be-11.cr08.ams-01.nl.leaseweb.net (81.17.35.185) 12.430 ms 12.247 ms 11.249 ms
7 po-1.ce18.ams-01.nl.leaseweb.net (81.17.35.69) 9.807 ms
po-1.ce17.ams-01.nl.leaseweb.net (81.17.35.67) 9.541 ms
po-2.ce17.ams-01.nl.leaseweb.net (81.17.35.71) 9.530 ms
In the Firewall-Logs of the master I get passed packets for that trace
When I do that trace on the backup-appliance I get no logged packets on the firewall of the backup-appliance...
Btw FYI: I use CARP-Interfaces as well
What if you use ping6 instead? As I said, maybe IPv6 is configured but not working properly.
In that case either fix IPv6 WAN config or disable in there.
Cheers,
Franco
Hi Franco,
the interfaces were all disabled for ipv6.
I went on investigating this issue and could isolate it a little bit more - what I absolutley don´t understand:
Here my procedure:
- I cloned the Master-VM
- I reconfigured the master-vm and changed the ip-addresses an so on to be the backup-appliance...
-> communication to "internet" doesn´t work.
Then I changed the IP-Address of the interface from 192.168.xxx.171 to 192.168.xxx.172. The rest stays the same. After that change the connection to the internet works and update is possible. - When I change it back to 171 then the connection is broken again. - reproduceable...
There are no firewall-rules configured (by myself) which block traffic from 171.
I have a working workaround for my problem, but it´s not solved.
Are there maybe any rules which are not presented in the GUI?
Hi Jimbeam128,
I had a very similar problem today, but managed to get it resolved with some of the info here and making some config changes - perhaps what I did will help you or some others.
In short, I had to update the 'point-to-point' devices to select my WAN port as the PPPoE interface. This was done by editing the PPPoE interface under 'Interfaces > Point-to-point > Devices' and then changing the 'Link Interfaces' to that of both my 'WAN' and the physical adapter (re0, in my instance).
The longer version is that the setup wizard when i first commissioned the box had also assigned a IPv6 config (or perhaps I'd accidentally set it, can't recall). Either way I'd had both a IPv4 and IPv6 config on my WAN since first run and whilst the tunnel would establish - it was creating some issues with connectivity (OPNsense updating was one of those).
After finding this thread I thought I'll clear up my stale IPv6 config once and for all; but didn't follow the cardinal rule......take a backup first! So this lead me down a ~30 minute rabbit hole to try and diagnose why the PPPoE config in the 'Interfaces > WAN' page was correct, but not establishing. It wasn't until I tried the 'Advances and MLPPP' link that lead me through to 'Interfaces > Point-to-point > Devices' that I saw the PPPoE interface was only bound to /dev/cu2. A quick edit to that config and connectivity resolved immediately.
Returning to perform a package update - the mirror addresses resolved straight away and updates are flowing! (for note, migrating from v23.1 to v23.7.9).
Might not fix your issue - but thought I'd mention what worked for me.