Clients on VLANs not receiving IPv6 addresses from Windows DHCP servers

[andrew_241]

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!

[dseven]

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....

[dseven]

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.

[andrew_241]

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.

[dseven]

You'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?

[andrew_241]

You'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.

[andrew_241]

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:

Code Select Expand

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:

...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?

[franco]

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

[YordiDR]

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.

[Smoky020]

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.

I got the same problem as you described. For reasons I am running a Kea DHCP server in a different subnet as the clients are on a different machine so I relay the traffic via opnsense's dhcp relay. The problem is that it uses the link-local address instead of the global ipv6 as link-address to forward the relay's and Kea won't be able to properly select a subnet. I do use correct class selection in Kea for subnet selection but it doesn't come to that stage yet.

/edit
When I go through the RFC 8415 it states that using a link-local address is not recommended but GUA is. Kea expects a GUA address as link-address. It is not a hard requirement though that a relay agent MUST use a GUA and may use a link-local instead.
https://datatracker.ietf.org/doc/rfc8415/

19.1.1.  Relaying a Message from a Client

   If the relay agent received the message to be relayed from a client,
   the relay agent places a globally scoped unicast address (i.e., GUA
   or ULA) from a prefix assigned to the link on which the client should
   be assigned leases into the link-address field.  If such an address
   is not available, the relay agent may set the link-address field to a
   link-local address from the interface on which the original message
   was received.  This is not recommended, as it may require that
   additional information be provided in the server configuration.  See
   Section 3.2 of [RFC7969] for a detailed discussion.

   This address will be used by the server to determine the link from
   which the client should be assigned leases and other configuration
   information.

   The hop-count value in the Relay-forward message is set to 0.

   If the relay agent cannot use the address in the link-address field
   to identify the interface through which the response to the client
   will be relayed, the relay agent MUST include an Interface-Id option
   (see Section 21.18) in the Relay-forward message.  The server will
   include the Interface-Id option in its Relay-reply message.  The
   relay agent sets the link-address field as described earlier in this
   subsection, regardless of whether the relay agent includes an
   Interface-Id option in the Relay-forward message.

And RFC 7969 has also some discussion about this
https://datatracker.ietf.org/doc/html/rfc7969#autoid-5

3.2.  DHCPv6-Specific Behavior

   The DHCPv6 protocol [RFC3315] defines two core mechanisms that allow
   a server to distinguish which link the relay agent is connected to.
   The first mechanism is the link-address field in the Relay-forward
   and Relay-reply messages.  The link-address field uniquely identifies
   the link and should not be mistaken for a link-local address.  In
   normal circumstances, this is the solution that is easiest to
   maintain, as existing address assignments can be used and no
   additional administrative actions (like assigning dedicated
   identifiers for each relay agent, making sure they are unique, and
   maintaining a list of such identifiers) are needed.  It requires,
   however, for the relay agent to have an address with a scope larger
   than link-local configured on its client-facing interface.