OPNsense Forum
Archive => 20.1 Legacy Series => Topic started by: IsaacFL on May 26, 2020, 06:10:55 am
-
New user to opnsense.
My WAN ipv6 gateway is a link local address and dpinger shows the gateway down.
In the Gateway Logs I see:
2020-05-25T20:46:37 dpinger: WAN_DHCP6 fe80::201:5cff:fe76:b846%hn0: sendto error: 65
If I try to ping I get:
# /sbin/ping6 -S 'fe80::21f:e1ff:fe10:e676%hn0' -c '3' 'fe80::201:5cff:fe76:b846'
PING6(56=40+8+8 bytes) fe80::21f:e1ff:fe10:e676%hn0 --> fe80::201:5cff:fe76:b846%hn0
ping6: wrote fe80::201:5cff:fe76:b846 16 chars, ret=-1
ping6: wrote fe80::201:5cff:fe76:b846 16 chars, ret=-1
ping6: wrote fe80::201:5cff:fe76:b846 16 chars, ret=-1
--- fe80::201:5cff:fe76:b846 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
ping6: sendmsg: No route to host
ping6: sendmsg: No route to host
ping6: sendmsg: No route to host
It seems to me that something is wrong with the route for link local on the WAN interface?
-
What's your ISP?
Can you check in your /tmp/ folder. and look for a *_routerv6 file, does it exist?
p.s following your thread on the pfSense forum - multiple-ipv6-capable-connections, interesting.
-
Also, can you post the output of netstat -6rW. Obfuscate any gua addresses, just interested in the default route.
-
I have the same problem with the ipv6 link-local address. I changed it to one of the google dns ipv6 addresses and it has worked since, modulo other problems with dpinger.
-
What's your ISP?
Can you check in your /tmp/ folder. and look for a *_routerv6 file, does it exist?
p.s following your thread on the pfSense forum - multiple-ipv6-capable-connections, interesting.
ISP is Time Warner/Spectrum in Southern California.
The file hn0_routerv6 does exist, its contents are:
fe80::201:5cff:fe76:b846
which is the gateway of the ISP
-
Also, can you post the output of netstat -6rW. Obfuscate any gua addresses, just interested in the default route.
root@OPNsense:~ # netstat -6rW
Routing tables
Internet6:
Destination Gateway Flags Use Mtu Netif Expire
default fe80::201:5cff:fe76:b846%hn0 UG 111414 1500 hn0
localhost link#1 UH 0 16384 lo0
64:ff9b::/96 fd04:6ddc:fe8e:2364:15:5dff:feff:2b04 UGS 35 1500 hn4
64:ff9b::424a:d401 fd04:6ddc:fe8e:2364:15:5dff:feff:2b04 UGHS 42464 1500 hn4
dns.google fe80::201:5cff:fe76:b846%hn0 UGHS 42480 1500 hn0
2605:e000:abcd:ef10::/64 link#6 U 27147 1500 hn1
2605:e000:abcd:ef10:15:5dff:feff:2b00 link#6 UHS 0 16384 lo0
2605:e000:abcd:ef20::/64 link#7 U 0 1500 hn2
OPNsense link#7 UHS 0 16384 lo0
2605:e000:abcd:ef30::/64 link#8 U 6858 1500 hn3
2605:e000:abcd:ef30:15:5dff:feff:2b02 link#8 UHS 0 16384 lo0
2605:e000:abcd:ef64::/64 link#9 U 0 1500 hn4
2605:e000:abcd:ef64:15:5dff:feff:2b03 link#9 UHS 0 16384 lo0
OPNsense link#5 UHS 0 16384 lo0
fd04:6ddc:fe8e:2310::/64 link#6 U 0 1500 hn1
OPNsense link#6 UHS 0 16384 lo0
fd04:6ddc:fe8e:2330::/64 link#8 U 2851 1500 hn3
OPNsense link#8 UHS 0 16384 lo0
fd04:6ddc:fe8e:2364::/64 link#9 U 44377 1500 hn4
OPNsense link#9 UHS 0 16384 lo0
fe80::%lo0/64 link#1 U 0 16384 lo0
fe80::1%lo0 link#1 UHS 0 16384 lo0
fe80::%hn0/64 link#5 U 25 1500 hn0
fe80::21f:e1ff:fe10:e676%hn0 link#5 UHS 0 16384 lo0
fe80::%hn1/64 link#6 U 1614 1500 hn1
fe80::15:5dff:feff:2b00%hn1 link#6 UHS 0 16384 lo0
fe80::%hn2/64 link#7 U 0 1500 hn2
fe80::15:5dff:feff:2b01%hn2 link#7 UHS 0 16384 lo0
fe80::%hn3/64 link#8 U 4126 1500 hn3
fe80::15:5dff:feff:2b02%hn3 link#8 UHS 0 16384 lo0
fe80::%hn4/64 link#9 U 3482 1500 hn4
fe80::15:5dff:feff:2b03%hn4 link#9 UHS 0 16384 lo0
root@OPNsense:~ #
-
I have the same problem with the ipv6 link-local address. I changed it to one of the google dns ipv6 addresses and it has worked since, modulo other problems with dpinger.
That is what I have done temporarily, but it should work.
Link Local Addresses are the most common gateways that I have seen.
It worked with pfsense, so something different here.
-
Can you do:
# ps auxw | grep dpinger
post the v6 entry... ta..
-
Sorry.. read the last message from you just after I posted. Can you post the none working and the working ps -auxw ....
-
Can you do:
# ps auxw | grep dpinger
post the v6 entry... ta..
root 50166 0.0 0.1 11008 2468 - Is 10:40 0:00.01 /usr/local/bin/dpinger -f -S -r 0 -i WAN_DHCP6 -B fe80::21f:e1ff:fe10:e676%hn0 -p /var/run/dpinger_WAN_DHCP6.pid -u /var/run/dpinger_WAN_DHCP6.sock -C /usr/local/etc/rc.syshook monitor -s 1s -l 2s -t 60s -A 1s -D 500 -L 20 -d 0 fe80::201:5cff:fe76:b846%hn0
-
Just to eliminate the firewall, I added a rule to WAN passing LLA to LLA out,
Then tried pinging using WAN interface, I can see in the firewall log, it passing out, but no response.
-
Sorry.. read the last message from you just after I posted. Can you post the none working and the working ps -auxw ....
Working using Google DNS as the monitor:
root@OPNsense:~ # ps auxw | grep dpinger
root 369 0.0 0.1 6912 2356 - Is 10:37 0:00.02 /usr/local/bin/dpinger -f -S -r 0 -i WAN_DHCP6 -B 2605:e000:ffc0:3a:3583:9dcc:d43b:b16e -p /var/run/dpinger_WAN_DHCP6.pid -u /var/run/dpinger_WAN_DHCP6.sock -C /usr/local/etc/rc.syshook monitor -s 1s -l 2s -t 60s -A 1s -D 500 -L 20 -d 0 2001:4860:4860::8844
Non-Working using default gateway:
root 50166 0.0 0.1 11008 2468 - Is 10:40 0:00.01 /usr/local/bin/dpinger -f -S -r 0 -i WAN_DHCP6 -B fe80::21f:e1ff:fe10:e676%hn0 -p /var/run/dpinger_WAN_DHCP6.pid -u /var/run/dpinger_WAN_DHCP6.sock -C /usr/local/etc/rc.syshook monitor -s 1s -l 2s -t 60s -A 1s -D 500 -L 20 -d 0 fe80::201:5cff:fe76:b846%hn0
-
Even more bizarre is this > My primary router works to my ISP using the link local address - ping or dpinger. My secondary test router to the primary router using link-local address does not ??? .
-
I am not sure if this is a valid test or not, but I opened 2 windows of opensense. One is doing packet capture my link local ip (fe80::21f:e1ff:fe10:e676) as host to capture.
the other window tried to ping. This is result:
# /sbin/ping6 -S 'fe80::21f:e1ff:fe10:e676%hn0' -c '3' 'fe80::201:5cff:fe76:b846'
PING6(56=40+8+8 bytes) fe80::21f:e1ff:fe10:e676%hn0 --> fe80::201:5cff:fe76:b846%hn0
ping6: wrote fe80::201:5cff:fe76:b846 16 chars, ret=-1
ping6: wrote fe80::201:5cff:fe76:b846 16 chars, ret=-1
ping6: wrote fe80::201:5cff:fe76:b846 16 chars, ret=-1
--- fe80::201:5cff:fe76:b846 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
ping6: sendmsg: No route to host
ping6: sendmsg: No route to host
ping6: sendmsg: No route to host
The capture was empty.
-
Well a lightbulb came on... VLANs... my primary LANs are all VLANs. So I was then able to ping out from the primary to the test router OK, but of course, not the other way.
Anyway.. I'll play with this tomorrow...
-
Well a lightbulb came on... VLANs... my primary LANs are all VLANs. So I was then able to ping out from the primary to the test router OK, but of course, not the other way.
Anyway.. I'll play with this tomorrow...
I can't think of anything unique to my setup. I am going to move on to using the dns.google address as monitors which works fine.
To really know for sure I would need to put a wireshark on the interface but I don't have that as an option here, lacking a switch to allow it.
-
To really know for sure I would need to put a wireshark on the interface but I don't have that as an option here, lacking a switch to allow it.
Interfaces / Diagnostics / Packet Capture is your friend. :)
Generated .cap files can be analysed with Wireshark.
-
OK, quick change this morning. As I said my problem was the VLANs. As soon as I changed the target IPs to the GUAs on the upstream router it all worked. So what I know is that link local is working fine to my ISP on my primary router.
-
OK, quick change this morning. As I said my problem was the VLANs. As soon as I changed the target IPs to the GUAs on the upstream router it all worked. So what I know is that link local is working fine to my ISP on my primary router.
Revisiting this. I had to finally switch back to pfsense, as there seems to be something not stable with the underlying gateway routing for ipv6. I kept having ipv6 gateway going down and not coming back up.
Dpinger and manually pinging my link local gateway on the WAN does work on pfsense but not opnsense.
See my earlier post to show the results of ping while on opnsense compared to currently installed pfsense.
# /sbin/ping6 -S 'fe80::21f:e1ff:fe10:e676%hn0' -c '3' 'fe80::201:5cff:fe76:b846%hn0'
PING6(56=40+8+8 bytes) fe80::21f:e1ff:fe10:e676%hn0 --> fe80::201:5cff:fe76:b846%hn0
16 bytes from fe80::201:5cff:fe76:b846%hn0, icmp_seq=0 hlim=64 time=8.143 ms
16 bytes from fe80::201:5cff:fe76:b846%hn0, icmp_seq=1 hlim=64 time=7.973 ms
16 bytes from fe80::201:5cff:fe76:b846%hn0, icmp_seq=2 hlim=64 time=8.248 ms
--- fe80::201:5cff:fe76:b846%hn0 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 7.973/8.121/8.248/0.113 ms
Also
# netstat -6rW
Routing tables
Internet6:
Destination Gateway Flags Use Mtu Netif Expire
default fe80::201:5cff:fe76:b846%hn0 UG 202454 1500 hn0
localhost link#1 UH 15084 16384 lo0
64:ff9b::/96 fe80::15:5dff:feff:2b04%hn4 UGS 3302 1500 hn4
64:ff9b::4884:1 fe80::15:5dff:feff:2b04%hn4 UGHS 155018 1500 hn4
2605:e000:abcd:ef10::/64 link#6 U 68460 1500 hn1
pfSense link#6 UHS 0 16384 lo0
2605:e000:abcd:ef20::/64 link#7 U 1821 1500 hn2
2605:e000:abcd:ef20:15:5dff:feff:2b0a link#7 UHS 0 16384 lo0
2605:e000:abcd:ef30::/64 link#8 U 13599 1500 hn3
vpn link#8 UHS 0 16384 lo0
2605:e000:abcd:ef64::/64 link#9 U 2033 1500 hn4
2605:e000:abcd:ef64:15:5dff:feff:2b0c link#9 UHS 0 16384 lo0
2605:e000:abcd:ef70::/64 link#10 U 0 1500 ovpns1
2605:e000:abcd:ef70::1 link#10 UHS 0 16384 lo0
2605:e000:ffc0:3a:496f:d316:d939:ac80 link#5 UHS 0 16384 lo0
one.one.one.one fe80::201:5cff:fe76:b846 UGHS 0 1500 hn0
resolver1.opendns.com fe80::201:5cff:fe76:b846 UGHS 0 1500 hn0
fe80::201:5cff:fe76:b846 fe80::201:5cff:fe76:b846%hn0 UGHS 0 1500 hn0
fe80::%lo0/64 link#1 U 0 16384 lo0
fe80::1%lo0 link#1 UHS 0 16384 lo0
fe80::%hn0/64 link#5 U 155181 1500 hn0
fe80::21f:e1ff:fe10:e676%hn0 link#5 UHS 0 16384 lo0
fe80::%hn1/64 link#6 U 998 1500 hn1
fe80::1:1%hn1 link#6 UHS 0 16384 lo0
fe80::%hn2/64 link#7 U 2938 1500 hn2
fe80::1:1%hn2 link#7 UHS 0 16384 lo0
fe80::%hn3/64 link#8 U 6833 1500 hn3
fe80::1:1%hn3 link#8 UHS 1 16384 lo0
fe80::%hn4/64 link#9 U 5823 1500 hn4
fe80::1:1%hn4 link#9 UHS 0 16384 lo0
fe80::%ovpns1/64 link#10 U 0 1500 ovpns1
fe80::21f:e1ff:fe10:e676%ovpns1 link#10 UHS 0 16384 lo0
-
I've already raised the issue on Github, it's a regression that's crept in somewhere.
-
I've already raised the issue on Github, it's a regression that's crept in somewhere.
Is this expected for 20.7 then?
-
I just looked at Monitor - Gateway issue #4172
One more detail that might be implied is that this is not just the gateway monitoring, something is keeping link local traffic from coming out of the WAN interface even for manual ping.
I did an earlier packet capture and there was no link local traffic coming out of the opnsense.
-
Yup.. noticed that. But the odd thing is that if you save the WAN interface after you have set the monitor to empty or default, it works. It's only when you change the gateway after or the interface goes down and back up on its own. Think it could be a filter thing, but it's not my area.
-
I think it is a routing issue for link local on the interface.
I thought it was a filter thing also at first, but couldn't find that to be the case. I thought that blocking bogons might be the issue, but unchecking block private and bogons on WAN didn't make a difference.
I couldn't see anything in the logs either.
-
I tried adding routes so it was identical to pfSense, still did not work. I will add this though. I ran up a both pf and op on HyperV, I could not get it to work at all on HyperV, I could get it to work sometimes on VMWare and on my Qotom ( there's a word I can type on this forum ) and my APU.
Whatever it is, it's a little bugger.
-
I am running this on Hyper-V. Maybe there is a clue in that. I don't have any dedicated hardware to test it that way.
-
Well once I can get the brain pair to figure out why it wont play nicely anyway - I'll then have another look at it in HyperV.
-
Don't think this has anything to do with Hyper-V.
I'm running mine on an appliance (Tometek MAX-TTS) and having the exact same issue.
-
I doubt it is hyper-v either as I am running pfsense fine in exact same configuration.
I guess for testing you could disable the pf filter completely to eliminate that.
Does opnsense use the same routing daemon as pfsense? It still seems like a bug in the routing to me.
-
Comparing netstat -6rW from my old opnsense to pfsense, I see that the opensense is missing this line:
fe80::201:5cff:fe76:b846 fe80::201:5cff:fe76:b846%hn0 UGHS 0 1500 hn0
-
Where my gateway LLA fe80::201:5cff:fe76:b846 and my rtr LLA fe80::21f:e1ff:fe10:e676
-
Has this issue been resolved in 2.1.8?
-
I've identified the issue, it's a firewall issue. If you go to firewall->Settings->Advanced and enable 'Disable force gateway' you'll find link-local monitoring works. I've informed Franco of my findings. No, not fixed in 20.1.8, hopefully next release.
p.s. You'll need to re-save the gateway or interface after you've made the change to the firewall setting.
-
Thanks marjohn56. Is this issue being tracked on a Github issue that we can follow? I seem to still be experiencing this issue on OPNsense 20.7.3, even with the 'Disable Force Gateway' option enabled. (I've re-applied the settings for the Gateway, the WAN interface, and even restarted the entire machine, but the WAN_DHCP6 monitor still reports 'Offline.')
-
What address is in your gateway monitor?
-
What address is in your gateway monitor?
The WAN_DHCP6 monitor shows that it's monitoring fe80::217:10ff:fe93:7715, which I believe is the default gateway in the routing table in System >> Routes >> Status.
ipv6 default fe80::217:10ff:fe93:7715%em0 UG 1571 1500 em0 WAN
-
I'll check this again on my test unit. It will take me a while as I'm busy with another project but I'll take a look and see if that 'fix' is still working. Something may have changed in 20.7.
-
No, you're right, it doesn't work now.. It is being tracked and Franco did a remote onto my systems and was able to see it, so not resolved yet as there are other v6 issues with a higher priority. In the meantime, set a GUA address, Google's DNS server or I use the BBC.
-
Thanks for confirming marjohn56! I'll use another server like you suggest and await a fix in a future release. :)
-
Just want to let you know that I've the same issue with 20.7.3 as well.
As mentioned by marjohn56 checking 'Disable automatic rules which force local services to use the assigned interface gateway' under Firewall -> Settings -> Advanced -> Multi-WAN seems to work.
However, it is only working when using my own link-local address as Monitor IP. Pinging any other public IPv6 address does not work.
-
I have two Opnsense routers. The one on Xfinity does not have this issue. The one on Spectrum does have the issue.
Is there anything I can do to help or provide additional information?
For now, I've done the cardinal sin of disabling IPv6 on the Spectrum as when the IPv6 routing fails, children yell at me. Best IPv6 routing notification system I could have implemented. =)
-
You could try changing the monitor ip to a public DNS instead of the default gateway. I was using resolver2.opendns.com (2620:119:53::53) as my monitor ip and had better results.
I finally switched back to pfSense because of this issue and lack of Avahi for ipv6.
-
Just want to update this topic, I have the same problem here and I have just updated today to OPNsense 20.7.6-amd64 and I'm running this on bare metal, so nothing virtualized. I still cannot ping my link local router GW directly from OPNsense - even though in the firewall it's all green aka allowed.
So I'm currently also not using IPv6 due to this issue, but I really hope with every release to see it fixed :-\. I'm happy to provide an help I'm able to contribute here to get this solved.