pfSense does not reply to NS sent by ISP router, ISP does not respond to DHCPv6 request as a result
-
@cnrd said in pfSense does not reply to NS sent by ISP router, ISP does not respond to DHCPv6 request as a result:
The problem here is that the DHCPv6 server have no idea about where to send the response, as pfSense is not responding to the NS: "Neighbor Solicitation for fe80::ae16:2dff:fe94:bbd3 from fe:33:42:10:c8:6b", so it has no idea about where fe80::ae16:2dff:fe94:bbd3 is.
Is that NS being sent to the correct address? Also, is it possible to do a packet capture? You can use Packet Capture in pfSense and download the capture file to post here.
-
@JKnott said in pfSense does not reply to NS sent by ISP router, ISP does not respond to DHCPv6 request as a result:
Is that NS being sent to the correct address?
Yes it's being sent to ff02::1:ff94:bbd3, pfSense' local-link address is fe80::ae16:2dff:fe94:bbd3
Also, is it possible to do a packet capture? You can use Packet Capture in pfSense and download the capture file to post here.
Here is a cap from pfSense, that is captured while reloading the WAN interface, to force it to send a DHCP request.
It is captured by pfSense with Interface set to WAN and Address Family set to IPv6
As before:
WAN: ac:16:2d:94:bb:d3
ISP DHCP servers: fe:33:42:10:c8:6b, e6:5d:37:84:53:17Also I'm not seeing any NS being blocked in the firewall log.
-
@cnrd said in pfSense does not reply to NS sent by ISP router, ISP does not respond to DHCPv6 request as a result:
Yes it's being sent to ff02::1:ff94:bbd3, pfSense' local-link address is fe80::ae16:2dff:fe94:bbd3
That ff02 address is a solicited node multicast, which is the other end trying to determine your MAC address. However, I don't know why it's doing that, as it should be able to find that in the solicit XID. Regardless, your system should be responding.
-
@JKnott Yeah, I'm not sure why they need that, but I don't think it's out of spec.
Regardless, your system should be responding.
Yeah this it the whole problem, it seems like the NS arrives at pfSense WAN interface, and running
pfctl -vvsrindicates that it is even allowed through the firewall?@11(1000000107) pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state [ Evaluations: 3509019 Packets: 554001 Bytes: 53687917 States: 0 ] [ Inserted: pid 72478 State Creations: 683 ]Do you have any idea about what I could try to figure this out?
Also thanks for the help you have already provided :-)
EDIT: Could it be related to the fact that the NS sent by the ISP DHCP server is sent from 2a00:7660::249, which is not a private address, therefor pfSense refuses to reply?
28 9.708786 2a00:7660::249 ff02::1:ff94:bbd3 ICMPv6 86 Neighbor Solicitation for fe80::ae16:2dff:fe94:bbd3 from fe:33:42:10:c8:6bAs you can see here the source is 2a00:7660::249 and the dest is ff02::1:ff94:bbd3 at this point in time pfSense only knows the address fe80::ae16:2dff:fe94:bbd3 which is not in the same space as 2a00:7660::249
-
@cnrd said in pfSense does not reply to NS sent by ISP router, ISP does not respond to DHCPv6 request as a result:
EDIT: Could it be related to the fact that the NS sent by the ISP DHCP server is sent from 2a00:7660::249, which is not a private address, therefor pfSense refuses to reply?
I wouldn't think so. While you can enable Unique Local Addresses (ULA) they're not needed. Normally, you have public addresses, at least 18.4 billion, billion of 'em.
ULA == the IPv6 equivalent of RFC 1918 addresses. -
@JKnott I'm simply lost at what to try, to get this to work at this point. I know what the root cause is, namely that there is no reply from pfSense for the NS, I know that the package arrives at the pfSense firewall, I know that it is passed through the firewall, but something behind the firewall simply isn't sending out a reply.
I even tried running with
pfctl -dto verify that it was not the firewall that caused the problem. -
Perhaps you can try an experiment. Connect another computer to the WAN port and try pinging the link local address and see what happens. Do a packet capture of it.
-
@JKnott I just connected my desktop directly to pfSense WAN port, pinging the WAN local-link address worked just fine, and the package-capture showed an NS sent from my desktop and an NA reply from pfSense.
Both machines here used local-link addresses, so I still suspect that the problem lies somewhere with the public address used by my ISP's dhcp servers.
Here is the capture (I only saved the relevant parts): NS-NA.pcapng
-
I also just tested it out on a totally clean install of both pfSense 2.4.5-RELEASE-p1 and a clean install of the latest 2.5-SNAPSHOT, no difference, pfSense is simply not replying.
-
Ping obviously works.
I just did a packet capture with Wireshark and a managed switch, configured as a data tap.
Here's what I see
neighbour solicitation for duplicate address detection
router solicitation
router advertisement
solicit XID
advertise XID
request XID
reply XIDI have attached the packet capture. How does yours compare? I've been using pfsense for almost 4 years and haven't seen it fail. It just works. In fact IPv6 was the reason I moved to pfsense, as the Linux firewall I was running didn't support DHCPv6-PD.
-
@JKnott Everything here is captured in the same way, Wireshark with a port mirror.
Here is the order:
duplicate address detection
solicit XID (x5)
neighbor solicit from 2a00:7660::248 and 2a00:7660::249This pattern repeats, as pfSense is waiting for a reply to the solicit XID and ISP routers are waiting for a reply to the neighbor solicits before sending a reply to the XID.
Interestingly I also tried setting up a pure FreeBSD 12.2 machine, just to see if that would reply to the NS, but no dice, so it seems that the problem lies somewhere below pfSense.
Here is a capture of that NS-no-response.pcapng
As you can see, same pattern, the ISP routers refuses to do anything before they get a reply to the NS they are sending out, while FreeBSD refuses to reply.
I know that everything will work, if I can just get pfSense/FreeBSD to reply to that NS, as I have experimented with Linux, which replies to the NS after which everything runs smoothly:
10 5.677136 2a00:7660::248 ff02::1:ffc9:11ee ICMPv6 86 Neighbor Solicitation for fe80::541e:337d:38c9:11ee from e6:5d:37:84:53:17 11 5.677141 fe80::541e:337d:38c9:11ee 2a00:7660::248 ICMPv6 86 Neighbor Advertisement fe80::541e:337d:38c9:11ee (sol, ovr) is at ac:16:2d:94:bb:d3 12 5.677527 2a00:7660::249 ff02::1:ffc9:11ee ICMPv6 86 Neighbor Solicitation for fe80::541e:337d:38c9:11ee from fe:33:42:10:c8:6b 13 5.677724 fe80::541e:337d:38c9:11ee 2a00:7660::249 ICMPv6 86 Neighbor Advertisement fe80::541e:337d:38c9:11ee (sol, ovr) is at ac:16:2d:94:bb:d3 14 5.678332 fe80::e65d:37ff:fe84:5317 fe80::541e:337d:38c9:11ee ICMPv6 78 Router Advertisement from e6:5d:37:84:53:17 15 5.678687 fe80::fe33:42ff:fe10:c86b fe80::541e:337d:38c9:11ee ICMPv6 78 Router Advertisement from fe:33:42:10:c8:6b -
@cnrd said in pfSense does not reply to NS sent by ISP router, ISP does not respond to DHCPv6 request as a result:
This pattern repeats, as pfSense is waiting for a reply to the solicit XID and ISP routers are waiting for a reply to the neighbor solicits before sending a reply to the XID.
pfsense startup.pcapng
Interestingly I also tried setting up a pure FreeBSD 12.2 machine, just to see if that would reply to the NS, but no dice, so it seems that the problem lies somewhere below pfSense.It looks to me like the problem is with the ISP, given the lack of responses. I assume your modem is in bridge mode, not gateway.
-
@JKnott I'm using a fiber modem, so there is no other routers in between.
I don't think it's a problem on my ISP's side, as everything works as soon as the client on my side replies to the NS send by the ISP router.
Booting into another OS that will reply to the ISP router NS and then back into pfSense results in pfSense getting both an IPv6 and a PD. The problem is that this only works for a couple of hours until the ISP router's cache run out and pfSense does not reply to the new NS send out at that time.
I'm starting to suspect that this may actually be a bug in the ND implementation of FreeBSD.
-
If whatever device is in gateway mode, pfsense will not work properly. Do you get NAT addresses on IPv4? If so, the modem is likely in gateway mode. I don't know what you have, but around here, the phone company provides fibre connections through the exact same device as they use for ADSL. It has connectors for both a phone line and Ethernet. If the customer is on fibre, then the Ethernet port connects to the fibre interface. I have a cable modem and the first thing I did when I got it, was to put it in bridge mode.
-
@JKnott there is no router function in the modem I have it is literally a fiber modem. I have a public IPv4 and in other OS'es than pfSense I get an IPv6-PD/NA.
-
Well, I don't know what else to tell you. It works fine for me and many others. But when I look at your capture and see all those unanswered solicitations I don't think the problem is with pfsense. You have to find out why the ISP is not responding to them. I see 14 lines of them and not a single response. While I don't see a router solicitation, I do see the solicit XID to a multicast address. Why no response to that?
What is your WAN config? Mine says DHCP6.
Also, in your first post you said "When pfSense sends out a DHCPv6 request, my ISP sends out an NS, which pfSense never replies to <-- This seems to be what causes the problem.", but I don't see that in the packet capture.
-
@JKnott yeah I don't really know what else there is to try either.
WAN is set to DHCPv6.
The NS from the ISP comes right after the XID in the latest capture.
All I can say is that in other OS'es it's working because they reply to that NS.
I don't really know what to ask my ISP about, as I haven't found any documentation/RFC showing that what they are doing is out of spec.
Anyways thanks for trying :-) as the same thing is happening upstream in FreeBSD, I'll probably try over there.
-
You might also mention who your ISP is. Someone else might have experience with them.
-
@JKnott My ISP is Gigabit.dk
As I wanted to test my theory that it would not reply to global addresses, I hand-crafted two different packages using scapy.
The only difference between these two packages is the fact that one uses a global IP as the src, while the other uses a local-link address.
I'm going to open a bug-report with those two minimal examples.
-
Not sure this is a bug.
How is an IPv6 host supposed to source a packet to a GUA unicast address from a link-local address? Link-local is link-local, not GUA. The host has no idea that the GUA address is on the next hop. If it is not, the router receiving the packet should not forward the packet if it is sourced from the link-local address. The host cannot source the packet from a GUA address because DHCP6 has not occurred yet (It doesn't have one).
I tried to find something hard in the RFCs that states this but came up empty.
macos to pfSense: Ping in the link-local context works: $ ping6 -S fe80::183d:38c9:7896:973b%vlan0 fe80::1:1%vlan0 PING6(56=40+8+8 bytes) fe80::183d:38c9:7896:973b%vlan0 --> fe80::1:1%vlan0 16 bytes from fe80::1:1%vlan0, icmp_seq=0 hlim=64 time=0.168 ms 16 bytes from fe80::1:1%vlan0, icmp_seq=1 hlim=64 time=0.151 ms 16 bytes from fe80::1:1%vlan0, icmp_seq=2 hlim=64 time=0.142 ms 16 bytes from fe80::1:1%vlan0, icmp_seq=3 hlim=64 time=0.225 ms ^C --- fe80::1:1%vlan0 ping6 statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.142/0.171/0.225/0.032 ms Ping link-local to GUA fails: $ ping6 -S fe80::183d:38c9:7896:973b%vlan0 2001:470:beef:1::1 PING6(56=40+8+8 bytes) fe80::183d:38c9:7896:973b%vlan0 --> 2001:470:beef:1::1 ^C --- 2001:470:beef:1::1 ping6 statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss Ping GUA to GUA works: $ ping6 -S 2001:470:beef:1:8444:5b18:abab:96f0 2001:470:beef:1::1 PING6(56=40+8+8 bytes) 2001:470:beef:1:8444:5b18:abab:96f0 --> 2001:470:beef:1::1 16 bytes from 2001:470:beef:1::1, icmp_seq=0 hlim=64 time=0.201 ms 16 bytes from 2001:470:beef:1::1, icmp_seq=1 hlim=64 time=0.203 ms 16 bytes from 2001:470:beef:1::1, icmp_seq=2 hlim=64 time=0.211 ms ^C --- 2001:470:beef:1::1 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.201/0.205/0.211/0.004 msIs this the same ISP that expected its customers to periodically send a Router Solicitation even though the RFCs explicitly state one MUST NOT do that except in certain instances like an interface reconfiguration, link down/up, etc?
