Project

General

Profile

Bug #11095

pfSense will not reply to NS on WAN where src is set to a global IPv6 address

Added by Conrad Andersen 2 months ago. Updated 2 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Operating System
Target version:
-
Start date:
11/23/2020
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.5-p1
Affected Architecture:

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.

not-working-pfsense-WAN.pcap (126 Bytes) not-working-pfsense-WAN.pcap Conrad Andersen, 11/23/2020 03:45 PM
not-working.pcap (112 Bytes) not-working.pcap Conrad Andersen, 11/23/2020 03:45 PM
working-pfsense-WAN.pcap (228 Bytes) working-pfsense-WAN.pcap Conrad Andersen, 11/23/2020 03:45 PM
working.pcap (112 Bytes) working.pcap Conrad Andersen, 11/23/2020 03:45 PM
debian.pcap (228 Bytes) debian.pcap Conrad Andersen, 11/24/2020 09:26 AM

History

#1 Updated by Jim Pingle 2 months 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.

#2 Updated by Conrad Andersen 2 months ago

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.

#3 Updated by Jim Pingle 2 months 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.

#4 Updated by Conrad Andersen 2 months 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.

Also available in: Atom PDF