IPv6 Neighbor Solicitation incorrectly retransmitted by PFSense?
-
You will probably have to provide a packet capture file pointing out exactly what you think is being done incorrectly.
SLAAC works fine on a pfSense interface.
When you connect a host it should send a Router Solicitation. In response it will get a Router Advertisement. From the information in that RA the host will choose a SLAAC address, set the gateway, DNS server(s), etc.
It could also just sit silently and wait for a periodic RA.
Neighbor discovery is more like ARP and shouldn't be adding addresses to interfaces in any case.
-
I've attached the two packets that show the unexpected behaviour.
-
Exactly what frame(s) do you believe to be incorrect and why?
-
There are only two frames in the capture. The first is the NS from the client, with IPs that are within the local link's prefix list. The second is the NS from PFSense that I believe shouldn't be sent at all.
-
I am unfamiliar with this fec0:: prefix. What is that?
-
fec0::/10 is the (deprecated) site-local prefix; as this is a local test network (as this is a test environment, it isn't using a globally-routable address).
-
Yeah I just found that. Why use something known to be deprecated.
-
I would use a current, proper ULA /48 for your test network to avoid people asking you silly questions when you raise a potential issue.
https://cd34.com/rfc4193/
-
Fine - I've reconfigured the test environment to use a proper ULA /48; as I expected, the behaviour is exactly the same (PFSense sending the multicast solicitation, and the client reporting a duplicate IP address from the PFSense MAC address and the target IP address).
-
You should be using unique local addresses, which are the entire fc:: /block. You should be able to find something in there.
-
You'll have to help me out in understanding why node fe80::20c:29ff:fe95:8b31 should pay any attention to a Neighbor Solicitation from Src: fd8c:60d0:4040:64:204:2ee:304d:132, Dst: fd8c:60d0:4040:64:204:2ee:304d:132 asking what the link address of fd8c:60d0:4040:64:204:2ee:304d:132 is.
Node fe80::20c:29ff:fe95:8b31 is sending a properly-formatted Neighbor Solicitation to node fd8c:60d0:4040:64:204:2ee:304d:132's proper solicited-node multicast address.
-
Unlike IPv4, IPv6 depends on link local addresses for things like RAs & RSs, among many others. A device will accept packets sent to it's link local, ULA or GUA addresses. They all contain the same MAC address, which is what determines whether a NIC accepts the packet. Multicasts, such as neighbour solicitation, use a multicast address where the lower 24 bits (IIRC) of the destination address will form part of that address.
BTW, if you want to learn about this sort of thing, I recommend IPv6 Essentials.
-
How does that explain the first frame in the packet capture that has been posted? What should the receiving host do with such an NS?
You seem to think nobody has any clue about how IPv6 works in every answer you give which have been pointing people to completely irrelevant information.
Chattanooga, Tennessee, USA
A comprehensive network diagram is worth 10,000 words and 15 conference calls.
DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
Do Not Chat For Help! NO_WAN_EGRESS(TM) -
The first frame would appear to be duplicate address detection, where a device checks to see if it's address is in use. The 2nd is just one device trying to find the MAC of another. In this case the destination is a multicast address, as I described above, as used with neighbour solicitation. Entirely normal.
-
Right. So we can wait for OP to outline exactly what is wrong with such behavior.
-
BTW, you can fire up Wireshark to see the RAs, NSs, etc. You will often see them coming from a link local address going to a ULA or GUA address.
-
Really?
