IPV6 issue related to Managed RA (freebsd 14)
-
Since two days I am running the FreeBSD14 version of 2.7
In first instance I noticed alarms a already described years ago in https://forum.netgate.com/topic/110239/occasional-warnings-in-ipv6-logs
"Jan 13 22:39:15 kernel cannot forward src fe80:4::c6e9:84ff
x, dst x0:1450:4009:80e::200e, nxt 6, rcvif igb1, outif igb0"Today I notices
- that they were related to my 100% actual windows10 pro PC
- and that the PC did not have IPV6 connectivity.
Changing the RA setting form ^managed^ to ^assisted^ did solve the problem.
However something is not OK, and the fact that it is occurring just after the upgrade from the 12.3 to 14 stable version ...... is verdict
-
That is not related to pfSense even, and the switch to assisted was likely unrelated as well.
The client at the
fe80address, which is a link local address, tried to send a packet to a globally routable address, and the kernel dropped it because that was not allowed.Link local addresses can never leave link local, but the client misbehaved and tried to use it as a global address.
Either way the problem here is a client issue, not pfSense.
-
Jimp I did test it a couple of times! and it is completely reproducible that it is not working if RA is Managed and that it starts working as soon as I change RA to Assisted.
C:\Users\Louis>ping -6 www.google.com
Pinging www.google.com [2a00:1450:400e:80e::2004] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.Ping statistics for 2a00:1450:400e:80e::2004:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),C:\Users\Louis>ping -6 www.google.com
Pinging www.google.com [2a00:1450:400e:802::2004] with 32 bytes of data:
Reply from 2a00:1450:400e:802::2004: time=2ms
Reply from 2a00:1450:400e:802::2004: time=2ms
Reply from 2a00:1450:400e:802::2004: time=2ms
Reply from 2a00:1450:400e:802::2004: time=2msPing statistics for 2a00:1450:400e:802::2004:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2msC:\Users\Louis>
I am not sure what is causing it, that is the next question. It could very well be a bug in windows10 pro 64bit or some setting somewhere.
What ever it is new since I updated to 2.7 new version (why not 2.8!?), which makes pfSense verdict IMHO.
I just repeated the test and did capture it with wireshark. I could share that as private file attached to a ticket
Louis
PS yep the fe80 is not correct I think but that is probably due to the RA process -
You'll need to look closer at what the client is getting and using for its IPv6 address(es) in each of those cases but as I said it's still the client selecting the wrong address for that communication, not pfSense.
