I've done an update to version OPNsense 23.1_6-amd64 last week. After that I noticed erros when trying to fetch new updates:
***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 23.1_6 at Mon Feb 27 08:49:43 CET 2023
Fetching changelog information, please wait... fetch: transfer timed out
Updating OPNsense repository catalogue...
I have done a lot of testing, switched mirrors, slept on it two nights and found out it might be a thing like https://forum.opnsense.org/index.php?topic=29992 (https://forum.opnsense.org/index.php?topic=29992), all traffic from unspecified interface left my opnsense with IP 0.0.0.0 (Wireshark screenshot attached).
There are no manual added entries in the NAT section, outbound NAT is set to Hybrid.
All traffic is working fine. The only remarkable thing is the stuck update function.
It would be very nice if someone could help me out to find a solutiuon for this. Please let me know what I can do to assist.
Thanks in advance, Ric.
Might be helpful:
root@apu2:~ # ifconfig | grep 0\\.0\\.0\\.0
syncpeer: 0.0.0.0 maxupd: 128 defer: off
root@apu2:~ # grep 0\\.0\\.0\\.0 /tmp/rules.debug
# block in log quick on igb0 inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "59eaa3b97b11c51ddfce6afe4f71eeb8" # Block private networks from LAN
# block in log quick on lo0 inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "9d59048c2ca76128e62ef15066bef954" # Block private networks from Loopback
# block in log quick on openvpn inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "d7a184385814e3ee66552f7d862ed84a" # Block private networks from OpenVPN
block in log quick on igb1 inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "1eb94a38e58994641aff378c21d5984f" # Block private networks from WAN
# block in log quick on wg0 inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "665c1956a6710524f6ed96b27b8144f5" # Block private networks from WireGuard
# block in log quick on wireguard inet from {10.0.0.0/8,127.0.0.0/8,100.64.0.0/10,172.16.0.0/12,192.168.0.0/16} to {any} label "86b9241a331e6d4aa0c7a30c2a2ea80c" # Block private networks from WireGuard (Group)
My crystal ball says you have default gateway switching active and not updated to 23.1.1 yet. ;)
Cheers,
Franco
Hi Franco, many thanks for your answer.
Default gateway switching is disabled. And updates are not working.
Is there an alternative way to do the updates?
Under normal circumstances the following should bring back the configuration:
# /usr/local/etc/rc.configure_interface
For some reason routes are applied to interfaces that don't have an IP address (yet) and the kernel handles this with a fixed host route with origin address 0.0.0.0 (which doesn't make much sense).
Cheers,
Franco
We are getting nearer Franco.
I ran the shell command and restarted, after that I was able to update to OPNsense 23.1.1.
Restarted again and now I see the same thing as before: fetch timed out.
So I noticed another strange thing. When I ping 89.149.211.205 (pkg.opnsense.org) there will be 0.0.0.0 as a source and no answer. But when I ping 8.8.8.8 the source is my external interface address.
Ping has been done from console:
root@apu2:~ # /sbin/ping -4 -c '2' '89.149.211.205'
PING 89.149.211.205 (89.149.211.205): 56 data bytes
^C
--- 89.149.211.205 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
root@apu2:~ # /sbin/ping -4 -c '2' '8.8.8.8'
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=14.665 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=13.666 ms
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
Packet captures are attached.
I'm not sure why it's doing the 0.0.0.0 yet but for 8.8.8.8 you probably have a host route through DNS entry or gatway monitor...
Cheers,
Franco
You are right Franco, 24 hrs later the host route is gone and it looks like:
root@apu2:~ # /sbin/ping -4 -c '2' '8.8.8.8'
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
root@apu2:~ # /sbin/ping -4 -c '2' '89.149.211.205'
PING 89.149.211.205 (89.149.211.205): 56 data bytes
--- 89.149.211.205 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
Is there anything I can do?
As a test I added an outbound NAT rule at WAN translating all sources 0.0.0.0 to WAN address and it worked.
I will enable this rule for doing updates only as I'm unsure about collateral damages of this setting. At least I'm able to do updates now and hopefully we will found the reason for this.
What I need to know is how you can end up with that bad host route...
What is your WAN connectivity? Is this reproducible after a reboot? Can you grep the log for me?
# opnsense-log | grep treating
Thanks,
Franco
First of all: please don't feel stressed Franco, system is running fine except of that. I'm very thankful you try to help me out there.
Done a reboot and get the same result, source address is 0.0.0.0.
root@apu2:~ # opnsense-log | grep treating
<13>1 2023-03-01T09:01:14+01:00 apu2.domain.tld opnsense 32004 - [meta sequenceId="47"] /usr/local/etc/rc.routing_configure: ROUTING: treating '46.140.98.81' as far gateway for ''
Ok, this was fixed in development release but was not yet backported.. now it is: https://github.com/opnsense/core/commit/cba3f43983
# opnsense-patch cba3f43983
(should be fine after reboot)
Cheers,
Franco
Salute Franco, works perfectly.
Many thanks and best regards.
Thanks a lot for your help! 8)