Unable to get dpinger to work on WAN ipv6 link local address

[IsaacFL]

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.

[Maurice]

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.

[marjohn56]

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.

[IsaacFL]

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

[marjohn56]

I've already raised the issue on Github, it's a regression that's crept in somewhere.

[IsaacFL]

I've already raised the issue on Github, it's a regression that's crept in somewhere.

Is this expected for 20.7 then?

[IsaacFL]

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.

[marjohn56]

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.

[IsaacFL]

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.

[marjohn56]

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.

[IsaacFL]

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.

[marjohn56]

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.

[mircolino]

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.

[IsaacFL]

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.

[IsaacFL]

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