Bug #11095
closed
pfSense will not reply to NS on WAN where src is set to a global IPv6 address
0%
Description
The category for this should probably be NDP, but that category is not available.
pfSense will not reply with an NA to an NS request that arrives on the WAN interface (not tested on other types of interfaces), if the IPv6 source address is a global IPv6 address.
pfSense will reply with and NA to an NS request that arrives on the WAN interface, if the IPv6 source address is a local-link address (fe80::)
I have attached 4 files which shows a minimal example.
working.pcap: A single hand-crafted package, that pfSense WILL reply to.
working-pfsense-WAN.pcap: A package capture from pfSense WAN interface, when the package is sent from another machine, as you can see this capture contain an NA response from pfSense.
not-working.pcap: A single hand-crafted package, that pfSense WILL NOT reply to.
not-working-pfsense-WAN.pcap: A package capture from pfSense WAN interface, when the package is sent from another machine, as you can see this capture does not contain an NA response from pfSense.
Files
Updated by Jim Pingle over 3 years ago
- Category changed from DHCP (IPv6) to Operating System
- Status changed from New to Rejected
That's up to the OS (FreeBSD) and not pfSense but I don't think your example is valid. You're sending a NS from global to link local, so I wouldn't expect it to respond.
pfSense responds to NS from global to global in the same prefix and from link local to link local.
Updated by Conrad Andersen over 3 years ago
- File debian.pcap debian.pcap added
pfSense responds to NS from global to global in the same prefix and from link local to link local.
Is it specified anywhere that this should be the case? As I'm not seeing the same behaviour on Linux based systems. They are able to respond to NS across global and link local.
See the attached capture from debian.
Updated by Jim Pingle over 3 years ago
I briefly searched and couldn't find anything that said it should work or that it was invalid, so it may vary by operating system.
I don't see how it makes sense logically, though, I did see several references saying that LL should only speak to/from LL since LL is not routable. I wouldn't expect anything to work at L2 between different prefixes, but again, it may vary by OS.
Either way if you have a valid real-world use case for that behavior (which seems unlikely) you should lobby to FreeBSD directly about the behavior, with documentation supporting its validity.
Updated by Conrad Andersen over 3 years ago
Thank you, my use case would be that; this is how my ISP's routers behave. I have send my ISP an email and I will wait for their response before I start pestering the FreeBSD bugzilla.