OPNsense Forum
Archive => 19.1 Legacy Series => Topic started by: abochem on March 10, 2019, 09:21:12 pm
-
I did a fresh OPNsense 19.1 install - upgraded to 19.1.3 afterwards, but this issue persists:
Scenario:
- Cable ISP with Fritz!Box at 192.168.178.1
- OPNSense box with two Realtek onboard NICs
- WAN on re1_vlan140 at 192.168.178.2 static IP
- Connected to the Fritz!Box via two switches with proper VLAN configuration.
- IPv6 set to "none" on all interfaces, not allowed in firewall settings
- Single IPv4 gateway configured with 192.168.178.1 (Fritz!Box)
- Single IPv6 gateway configured, but disabled.
- Fritz!Box does WLAN.
- OPNsense set to serve DHCP on WAN.
Problem:
After every boot of OPNsense, at first:
- Gateway is down - no internet connectivity. Disabling gateway monitoring does not help!
- Ping from OPNsense to 192.168.178.1 immediately returns: ping: sendto: Invalid argument
- Ping to any other host on 192.168.178.0/24 works, though!
- Even hosts on WLAN can be pinged (switched through Fritz!Box).
- WLAN devices successfully get their DHCP from OPNsense (switched through Fritz!Box)
- Manually saving the WAN interface configuration again makes the ping work and gateway accessible. - Until next reboot!
- Simply navigating to Interfaces -> WAN and clicking "Save", then "Apply".
- Without(!) changing any interface settings.
Having to resort to manual intervention after every reboot just to get basic connectivity working really is a pain!
I am out of ideas what might cause this. Being able to ping everything else in the same network across several network switches seems proof that my configuration is basically correct.
Is this a bug in OPNsense, or did I miss something really stupid?
Anyone have a clue what is going on here?
(edit)
Update
Alright, after writing down all my results here, I turned to playing with OPNsense GUI themes - and that brought out another related fact:
Every time I saved Systems -> Settings -> General, the issue re-appeared even without a reboot!
Again, saving Interfaces -> WAN fixed it for the time being.
After some experimentation, I found:
I had set DNS server 192.168.178.1 explicitly, and explicity set "use gateway" to the configured WANGW with the same IP as well.
When I set "use gateway" behind the DNS server entry to "none", the problem disappears.
However, this still smells like a bug to me? How is setting a (correct!) gateway supposed to cause ping issues?
-
DNS servers set host routes to gateways when selected. The monitoring IP will as well. Something likely isn't in sync with these two gateways hence the one host route overwriting the other.
Check routing table in working state and broken:
# netstat -nr
Cheers,
Franco
-
Hi franco,
find both outputs below in side-by-side diff.
The only difference in broken state is an explizit route for 192.168.178.1 to be send via 192.168.178.1 - which certainly looks redundant to me, but not incorrect in principle?
cheers,
Andreas
~ >>> diff -y routes_working.txt routes_broken.txt
root@OPNsense:~ # netstat -nr root@OPNsense:~ # netstat -nr
Routing tables Routing tables
Internet: Internet:
Destination Gateway Flags Netif Expire Destination Gateway Flags Netif Expire
default 192.168.178.1 UGS re1_vlan default 192.168.178.1 UGS re1_vlan
127.0.0.1 link#4 UH lo0 127.0.0.1 link#4 UH lo0
172.27.10.0/24 link#7 U re0_vlan 172.27.10.0/24 link#7 U re0_vlan
172.27.10.1 link#7 UHS lo0 172.27.10.1 link#7 UHS lo0
172.27.20.0/24 link#8 U re0_vlan 172.27.20.0/24 link#8 U re0_vlan
172.27.20.1 link#8 UHS lo0 172.27.20.1 link#8 UHS lo0
172.27.30.0/24 link#9 U re0_vlan 172.27.30.0/24 link#9 U re0_vlan
172.27.30.1 link#9 UHS lo0 172.27.30.1 link#9 UHS lo0
192.168.178.0/24 link#10 U re1_vlan 192.168.178.0/24 link#10 U re1_vlan
> 192.168.178.1 192.168.178.1 UGHS re1_vlan
192.168.178.2 link#10 UHS lo0 192.168.178.2 link#10 UHS lo0
Internet6: Internet6:
Destination Gateway Destination Gateway
::1 link#4 ::1 link#4
fe80::%re0/64 link#1 fe80::%re0/64 link#1
fe80::201:2eff:fe81:33ff%re0 link#1 fe80::201:2eff:fe81:33ff%re0 link#1
fe80::%re1/64 link#2 fe80::%re1/64 link#2
fe80::201:2eff:fe81:3400%re1 link#2 fe80::201:2eff:fe81:3400%re1 link#2
fe80::%lo0/64 link#4 fe80::%lo0/64 link#4
fe80::1%lo0 link#4 fe80::1%lo0 link#4
fe80::%re0_vlan10/64 link#7 fe80::%re0_vlan10/64 link#7
fe80::201:2eff:fe81:33ff%re0_vlan10 link#7 fe80::201:2eff:fe81:33ff%re0_vlan10 link#7
fe80::%re0_vlan20/64 link#8 fe80::%re0_vlan20/64 link#8
fe80::201:2eff:fe81:33ff%re0_vlan20 link#8 fe80::201:2eff:fe81:33ff%re0_vlan20 link#8
fe80::%re0_vlan30/64 link#9 fe80::%re0_vlan30/64 link#9
fe80::201:2eff:fe81:33ff%re0_vlan30 link#9 fe80::201:2eff:fe81:33ff%re0_vlan30 link#9
fe80::%re1_vlan140/64 link#10 fe80::%re1_vlan140/64 link#10
fe80::201:2eff:fe81:3400%re1_vlan140 link#10 fe80::201:2eff:fe81:3400%re1_vlan140 link#10
fe80::%re1_vlan150/64 link#11 fe80::%re1_vlan150/64 link#11
fe80::201:2eff:fe81:3400%re1_vlan150 link#11 fe80::201:2eff:fe81:3400%re1_vlan150 link#11