DHCP6 Client generates LL-T DUID from hardware MAC even when MAC is spoofed to a different value
-
I'm having difficulties with DHCPv6 in a Comcast home network after upgrading my pfSense hardware. For a few days I was able to get it to work by spoofing the MAC address on the new system to the old system's MAC.
Now, I seem to have lost IPv6 entirely. I get a delegated prefix /64, and pfSense uses it for LAN hosts, but IPv6 packets never see a response. They exit the WAN adapter (checked with tcpdump) but no replies are received.
Could this be a result of a mismatch between the MAC provided in the DHCP SOLICIT Client Identifier section (the real hardware MAC) not matching the spoofed MAC? Should pfSense be sending the spoofed MAC in the DHCP SOLICIT?
Here's a pcap of the DHCPv6 transaction
dhcp6b.pcapAdditional info - I tried pinging an external host that has IPv6, and where I have a shell and root access:
- Ping 6 from pfSense - works correctly
- Ping 4 from LAN host - works correctly
- Ping 6 from LAN host - ICMPv6 packets are seen to exit pfSense's WAN interface, but do not arrive at the remote host.