Clients on VLANs not receiving IPv6 addresses from Windows DHCP servers

Started by andrew_241, February 02, 2025, 09:56:11 AM

Previous topic - Next topic
I noticed a couple weeks ago that clients connected to my VLANs weren't receiving IPv6 addresses from my Windows DHCP servers. They do receive IPv4 addresses just fine. I think the Windows DHCP servers are configured correctly, so I'm wondering if there's something wrong with my OPNsense system. I have router advertisements set to 'Managed' for the LAN (clients there get assigned IPv6 addresses without any issues) and the two VLANs. 'Advertise Default Gateway' is checked, no route advertisements are specified, and 'Do not send any DNS configuration to clients' is checked. But, if radvd is set to 'Assisted', 'Unmanaged', or 'Stateless', the VLAN clients will get IPv6 addresses using SLAAC, not through the Windows servers though. DHCRelay is configured with the IPv4 and IPv6 addresses of the two Windows DHCP servers. I use Ubiquiti Networks Unifi switches, and DHCP snooping is disabled for both VLANs. 'Rogue DHCP Server Detection' is also disabled. A packet capture shows that there are DHCPv6 solicitations that are being transmitted from the clients (destination of ff02::1:2). Am I missing something here?

Thanks!

Do you have a DHCPv6 Relay service running for the VLAN in question? (check System > Diagnostics > Services). I've not actually used this myself, but it appears that you have to create separate "Destinations" for v4 and v6, then, for each interface, create separate "Relays" for each "Destination". It also appears that (at least in my 25.1 test instance), the resulting services do not get started automatically, so I had to start them under [System > Diagnostics > Services]. I haven't tested if they actually work, but they do appear to be running and listening now....

P.S. I notice that dhcrelay6 appears to listen on all interfaces, so I suspect that it may not be able to coexist with dhcpd6.

Yep, under 'System: Diagnostics: Services', there are two dhcrelay services, one each of DHCPv6 for both opt1 (vlan01) and opt2 (vlan02). Both those are running. A screenshot of 'Services: DHCRelay: Configuration' is attached. You're correct that dhcp6d won't run when dhcrelay is running on the same interface.

Quote from: andrew_241 on February 03, 2025, 04:34:49 AMYou're correct that dhcp6d won't run when dhcrelay is running on the same interface.

I was more concerned by the fact that it doesn't seem to listen on specific interfaces, but it appears that the SO_REUSEADDR socket option would allow both to listen on the same port at the same time.

So, have you tried a packet capture (for port 547) on the interface that the DHCP server is routed through?

Quote from: dseven on February 03, 2025, 12:01:22 PM
Quote from: andrew_241 on February 03, 2025, 04:34:49 AMYou're correct that dhcp6d won't run when dhcrelay is running on the same interface.

I was more concerned by the fact that it doesn't seem to listen on specific interfaces, but it appears that the SO_REUSEADDR socket option would allow both to listen on the same port at the same time.

So, have you tried a packet capture (for port 547) on the interface that the DHCP server is routed through?

I did, and I saw the DHCPv6 solicit and relay-forward messages. No response from the server though.

I'm messing around with this again with the help of Google's AI.

Here is a fragment of a packet capture. 2***:****:****:e97f::2 is the domain controller running the DHCP server, and 2***:****:****:e97f::1 is the main LAN interface's static IPv6 address:

Frame 42: Packet, 193 bytes on wire (1544 bits), 193 bytes captured (1544 bits)
Ethernet II, Src: Intel_ff:09:6b (68:05:ca:ff:09:6b), Dst: Microsoft_01:04:01 (00:15:5d:01:04:01)
Internet Protocol Version 6, Src: 2***:****:****:e97f::1, Dst: 2***:****:****:e97f::2
User Datagram Protocol, Src Port: 547, Dst Port: 547
DHCPv6
    Message type: Relay-forw (12)
    Hopcount: 0
    Link address: fe80::6a05:caff:feff:96b
    Peer address: fe80::103c:445d:15f3:943e

After some time troubleshooting, this was the AI's opinion on the matter:

Quote...this packet capture confirms OPNsense is doing something very specific: it is using its Main VLAN IP (...e97f::1) to send the packet, but it is putting the IoT Link-Local IP (fe80::...) inside the Link address field.

Windows Server sees that fe80 inside the "Link address" box and says, "I don't have a scope for fe80, so I'm ignoring this."

To fix this, we have to force the dhcp6relay binary to use the Global IP for that internal field.

So, is this a limitation of Windows Server, dhcp6relay, or is the AI just hallucinating?

Since you redacted the IPv6 relay IP and we don't know if you have IPv6 addresses on your LAN network it's hard to infer what the issue might be.

The relay address needs to be ping-able from the LAN address for starters.


Cheers,
Franco

I've got the same issue.
I'm running ISC DHCP on separate containers. This is working fine with DHCrelay on IPv4.
On IPv6, the DHCP servers are failing to assign addresses because they cannot map the incoming relayed DHCP request to a DHCP pool.
I also saw the OPNsense DHCrelay set the link-address to it's link-local address. If it would send it's GUA address instead, the DHCP server could map it to the correct GUA pool.