DHCPv6 broken for spoofed MAC

[tlschroe]

Hey everyone,

I have been a user for a few years after many years with the other sense.  The progress that OPNsense has made in that time has been amazing.

I am running a single-NIC system with vlans and a smart switch to segregate WAN and LAN ports.  My ISP is Comcast.

I had never been able to obtain an IPv6 address from my ISP on my WAN port despite knowing that it should be available.  I finally managed to obtain an IPv6 address while testing a USB NIC as my WAN port.  As expected, the USB NIC wasn't very stable, but it demonstrated that IPv6 was available.

After seeing IPv6 work on my connection, I decided to do a packet capture on the WAN to see what was happening with DHCPv6 on my original setup.  My box was sending solicit packets, but I didn't see any responses from the ISP.  I switched to promiscuous mode and still saw no responses.

I started digging into the DHCPv6 protocol to see if my solicit messages had any obvious problems when Wireshark did me a big favor...  it decoded the link-local source address of my packet to give me the MAC address of my WAN port.  Only it wasn't the current MAC address of my WAN port.  It was the burned-in MAC address of the card instead of the spoofed MAC address that I had entered when configuring the interface.

My packets had a mismatch between the ethernet MAC address and the MAC address that was encoded in the link-local IPv6 address.  I speculated that the equipment at Comcast must have noticed this and not responded to my solicit packets.

I used ifconfig to delete the existing link-local address from the WAN interface, generated a new link-local address from the spoofed MAC address, and then added this address to the WAN interface.

IPv6 started working almost instantly.

After several false starts, I discovered a workaround that could be fully implemented from within the existing GUI (and more importantly to me, backed-up in config.xml):

I added System -> Settings -> Tunables:  net.inet6.ip6.auto_linklocal = 0

Then under Interfaces -> Virtual IPs -> Settings: I added the link-local address that was calculated from my spoofed MAC address to the WAN interface with a /64 mask.

This is an issue that should probably be fixed for spoofed MAC addresses.  At the very least, a warning should be added to the help entry that spoofing may not work for DHCPv6.  Ideally, one of the alternate types of link-local addresses that don't derive from the MAC address should be used,

I don't know how many ISPs may be using equipment that does this type of checking.  I don't know how many people use MAC spoofing.  I don't know how disabling "auto_linklocal" might impact IPv6 connectivity on a multi-nic system.  (Hint: might need to manually add a link-local Virtual IP for each interface).

Just wanted to share this workaround with the community.

This post seems to reference the same problem:
https://forum.opnsense.org/index.php?topic=13561.0

[tlschroe]

Decided to create a TLDR:

The kernel will automatically generate an IPv6 link-local address for an interface when it is created (or first brought up... don't remember).

For the Realtek driver and likely others, the generated link-local address is derived from the burned-in MAC address of the interface.

The DHCPv6 server at my ISP (Comcast) appears to check to see if the MAC address from a DHCPv6 packet matches the link-local address of the IPv6 message within the packet.

If they don't match, it doesn't reply.

For a spoofed/cloned MAC address, they won't match.

Relatively simple and clean workaround from within the GUI is detailed above.

[Gauss23]

Thank you for your good research.

Would you mind creating an issue at the OPNsense GitHub repo?
This way there is a higher chance to integrate your solution.

[tlschroe]

Done.

https://github.com/opnsense/core/issues/4430

As an ammendment to my workaround:

After globally disabling auto_linklocal, I did also need to create a Virtual IP to create a link-local address on the LAN interface.  Otherwise, IPv6 would not work on LAN clients.