pfSense does not reply to NS sent by ISP router, ISP does not respond to DHCPv6 request as a result

Derelict

This is why I always tell people it is better to just call the ISP and get them to do whatever it is they need to do instead of relying on hacks like MAC address spoofing.

It is almost always better to fix the problem correctly than to paper over it so it can come back and bite you in unexpected ways at some unexpected time in the future. NAT reflection and, without a doubt, any routing asymmetry fall into this category. As does correcting misapplied public addresses instead of using RFC1918 (and a random choice at that).

Was the captured negotiation that was failing using the hardware or the spoofed MAC address?

cnrd

@Derelict there are two different people in this thread using the same ISP @abw and me. @abw seems to have his problem fixed, I however have never used a spoofed MAC, but still have problems.

Derelict

@abw said in pfSense does not reply to NS sent by ISP router, ISP does not respond to DHCPv6 request as a result:

My old statically coded MAC address OUI was bc:05:43

Not a locally-generated MAC address, which is the second-least-significant bit as 1 in the first octet there.

Derelict

@cnrd I understand that. I wasn't really talking to you but everyone in general.

cnrd

@Derelict sorry I had a million things going on when I wrote that reply.

It seems like I finally have it solved, thanks to @abw, who had the following system tuneable set: net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Setting this tuneable combined with doing something will allow pfSense to reply. In my case just applying the tuneable was not enough, restarting did not fix it, saving and applying the WAN interface did not fix it, I had to change and apply the DUID for the tunable to finally apply.

As stated here: https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc

The solution described below causes IPv6 Neighbor Discovery Neighbor Solicitation messages from non-neighbors to be ignored.
This can be re-enabled if required by setting the newly added net.inet6.icmp6.nd6_onlink_ns_rfc4861 sysctl to a non-zero value.

I think a package coming from a global address to a link local would be considered a non-neighbor.

abw

Ran a few more tests, and also concluded that the net.inet6.icmp6.nd6_onlink_ns_rfc4861 tunable is necessary, but the effect can only be seen after the VLTIME DHCP interval has expired.

I disabled the 'RFC4861 tunable completely, and rebooted. Everything comes up just fine, but after a couple of hours, corresponding to the DHCP6 VLTIME, the WAN IPv6 lease fails to renew, and IPv6 RAs disappear from all interfaces (I'm using Track Interface on the relevant interfaces). This appears to indicate that this tunable is necessary.

So, for my issue at least, it appears to be the combination of NOT using a statically configured MAC AND using the 'RFC4861 tunable, has fully resolved the issue with this ISP. It has been stable overnight, and looks very promising.
@Derelict

This is why I always tell people it is better to just call the ISP and get them to do whatever it is they need to do instead of relying on hacks like MAC address spoofing

Absolutely agree with this in principle (keep it simple), however it is still a useful feature. Now that I have a responsive and technically proficient ISP, there is no need to spoof anything, however my previous ISP had no useful process for handling a MAC change if I wanted to retain the static IP I had. The instruction to register a new MAC address was to turn off the CPE for 24 hours, which was not acceptable for me, as I am hosting a number of services.

Anecdotal for sure, however just want to point out that this was an invaluable feature for me dealing with hardware failure, and that there are likely other use cases, perhaps also depending on the support level, contactability and proficiency of the ISP involved.

Was the captured negotiation that was failing using the hardware or the spoofed MAC address?

The failing NS (i.e. soliciting no response from pfSense) was sent to a multicast MAC, consisting of 33:33:FF and then the last 3 octets of my spoofed MAC address.

@cnrd Thanks for not giving up, and for pushing this issue. Very happy that it's working for you now too.

JKnott

@Derelict said in pfSense does not reply to NS sent by ISP router, ISP does not respond to DHCPv6 request as a result:

This is why I always tell people it is better to just call the ISP and get them to do whatever it is they need to do instead of relying on hacks like MAC address spoofing.

The problem with that is they might not know. I have decades of experience in telecom, computers and networks and I like to dig down into the details, further than my co-workers would ever go. As a result, I was often the person they'd come to with problems they couldn't solve. In my experience with my own ISP I'll often not even bother with first level support, as I know the problem is likely to be well beyond them and I've even had to educate 2nd level and senior support. There have been a couple of times when a problem got resolved solely because I was able to work through it on my own. I would then have a struggle convincing the support people, because they simply weren't capable of working at that level. One example of this, which I have described here, was a problem with my ISPs CMTS, which I had identified right down to the host name of the failing system in their head end office.

While many support staff understand the basics of IP, they don't know the nitty, gritty details. This is particularly true with IPv6, as it's so new to them.

JKnott

@cnrd said in pfSense does not reply to NS sent by ISP router, ISP does not respond to DHCPv6 request as a result:

As stated here: https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc

The solution described below causes IPv6 Neighbor Discovery Neighbor Solicitation messages from non-neighbors to be ignored.
This can be re-enabled if required by setting the newly added net.inet6.icmp6.nd6_onlink_ns_rfc4861 sysctl to a non-zero value.

I think a package coming from a global address to a link local would be considered a non-neighbor.

Here is what I read on Redit:

"II. Problem Description

IPv6 routers may allow "on-link" IPv6 nodes to create and update the
router's neighbor cache and forwarding information. A malicious IPv6 node sharing a common router but on a different physical segment from another node may be able to spoof Neighbor Discovery messages, allowing it to update router information for the victim node."

Now, take a look at the packet containing the neighbour solicitation or advertisement and check the hop limit. It is 255. This is protection against that threat as a router would have to decrement it from 0, but a 0 hop limit would cause the packet to be dropped. This guarantees the packet originated on the local network. If it's any other number, the packet originated elsewhere and with a hop limit other than 255 or 0.