VLAN and DHCP Relay Issues on Hyper-V

Started by phwon, April 29, 2024, 05:00:59 PM

Previous topic - Next topic
April 29, 2024, 05:00:59 PM Last Edit: April 30, 2024, 05:56:05 PM by phwon
Hi,
Need some help please with a VLAN config.

I have one physical nic that I have created VLANS:

VLAN_10 - 192.168.10.254
VLAN_20 - 192.168.20.254

I have enabled DHCP Relay on all DHCP Server 192.168.10.1

When a device boots in VLAN_20 the DHCP server in VLAN_10 gets the request and sends the offer correctly to 192.168.20.254 but it's not received by the device.

Networks are not my thing but I'm guessing there is an issue with the route back to 192.168.20.254. Can't see anything being blocked on the firewall.

All inter vlan comms work if I assign static IPs; I can ping both ways.

What config am I missing?

Appreciate any advice.

Thanks

Quote from: phwon on April 29, 2024, 05:00:59 PM
When a device boots in VLAN_20 the DHCP server in VLAN_10 gets the request and sends the offer correctly to 192.168.20.254 but it's not received by the device.

I am not very familiar with DHCP relaying in production but either there is a typo in that line or I can at least point at something that I guess is related to the problem.

The DHCP server is in VLAN 10, a client in VLAN 20 ask for an address. The request gets relayed from VLAN 20 into VLAN 10 to the server - the source address of the relay is 192.168.10.254 as seen by the DHCP server. The reply by the server should go back to 192.168.10.254 and then be relayed into VLAN 20 by the DHCP relay.

If it doesn't happen, something off. Possibly asymmetrical routing. Why would the DHCP relay contact the server with a source address of .20.254 (VLAN 20)?
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Why are you setting up a DHCP relay? It is solely for remote networks that the DHCP server cannot listen to via broadcast. I think you would have problems if your OpnSense can both listen to the boardcasts and still gets a routed DHCP request.

With a "usual" setup, all you need is to enable ISC DHCP on every VLAN interface.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Their DHCP server is not on their OPNsense. It's in VLAN 10 at 192.168.10.1 according to the initial post. OPNsense should relay for VLAN 20.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Patrick M. Hausen on April 29, 2024, 06:13:14 PM
Why would the DHCP relay contact the server with a source address of .20.254 (VLAN 20)?

This is the behaviour that I see when DHCP Relay is enabled. It uses the interface of VLAN20 as the source.

Similar to Op, DHCP relay is also no longer working for me since upgrading to 24.1.6.


Quote from: meyergru on April 29, 2024, 06:44:46 PM
Why are you setting up a DHCP relay? It is solely for remote networks that the DHCP server cannot listen to via broadcast. I think you would have problems if your OpnSense can both listen to the boardcasts and still gets a routed DHCP request.

With a "usual" setup, all you need is to enable ISC DHCP on every VLAN interface.

I have a specific need to have a Windows DHCP server and you can't broadcast over different VLANS. This has to be manged by the Relay\IP helper. The IP helper forwards the request to the DHCP server, the client doesn't yet have an IP so the DHCP server sends the response to the switch and the switch forwards to the requesting client - at least that's what should be happening.

Yes. I understood that. You have a Windows DHCP server connected to one of your VLAN. However, normally, you would configure your switches to relay DHCP request to that. This is entirely done via routing.

Normally, I would not expect to configure anything besides firewall rules and routes to access the DHCP server on the OpnSense. If your switches can relay,, that is.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

DHCP relay is a function of a device capable L3. Basically your 1st device in the chain acting as a GW should be the Relay Gateway.

Relay works in a way where the GW changes the source IP (either 0.0.0.0 on discovery or unique private address on re-release) for GIADDR, which is used by the DHCP server as destination. Relay GW is an intermediator, asking on behalf the Host and replying on behalf the DHCP server.

I am currently running 24.1.6, my Relay config was migrated automatically from ISC to the new DHCPRelay implementation by OPNsense and its working.

Can you check your DHCPrelay config? The old section under ISC should be gone and a new service TAB called DHCPRelay should be under Services, there should be the Relay config present.

Regards,
S.
Networking is love. You may hate it, but in the end, you always come back to it.

OPNSense HW
APU2D2 - deceased
N5105 - i226-V | Patriot 2x8G 3200 DDR4 | L 790 512G - VM HA(SOON)
N100   - i226-V | Crucial 16G  4800 DDR5 | S 980 500G - PROD

Quote from: meyergru on April 30, 2024, 12:30:12 PM
Yes. I understood that. You have a Windows DHCP server connected to one of your VLAN. However, normally, you would configure your switches to relay DHCP request to that. This is entirely done via routing.

Normally, I would not expect to configure anything besides firewall rules and routes to access the DHCP server on the OpnSense. If your switches can relay,, that is.
What if the switch is strictly layer 2 and the OPNsense does all the routing? As I would expect given the initial post. And as I run everywhere, because the point is to filter/firewall between VLANs.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Seimus on April 30, 2024, 12:42:55 PM
DHCP relay is a function of a device capable L3. Basically your 1st device in the chain acting as a GW should be the Relay Gateway.

Relay works in a way where the GW changes the source IP (either 0.0.0.0 on discovery or unique private address on re-release) for GIADDR, which is used by the DHCP server as destination. Relay GW is an intermediator, asking on behalf the Host and replying on behalf the DHCP server.

I am currently running 24.1.6, my Relay config was migrated automatically from ISC to the new DHCPRelay implementation by OPNsense and its working.

Can you check your DHCPrelay config? The old section under ISC should be gone and a new service TAB called DHCPRelay should be under Services, there should be the Relay config present.
Regards,
S.

Config is there, and the request is being relayed to the DHCP server, the DHCP is responding with the offer to the originating VLAN gateway but it does not appear to be hitting the gateway.

Using Wireshark and looking at the offer you can see the destination is 192.168.20.254 and the DHCP offer is correct IP leased, correct MAC address etc


As a data point it would help to know if this is is a version before 24.1.6 or if this started with 24.1.6. If we don't have these data points it's harder to narrow this down (even if it is just a configuration hiccup).


Cheers,
Franco

Quote from: franco on April 30, 2024, 04:05:36 PM
As a data point it would help to know if this is is a version before 24.1.6 or if this started with 24.1.6. If we don't have these data points it's harder to narrow this down (even if it is just a configuration hiccup).


Cheers,
Franco

OPNsense 24.1.6-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13

As a bit of history I have always used VYOS - I had attempted this before on version 22.7 but had the same DHCP relay issue. I'm now reattempting to use OPNsense, upgraded to 24.1.6 but issue remains.

Sounds like networking hiccup. Are you spoofing VLAN MAC addresses? Switch discarding the packet on the way back?


Cheers,
Franco

Problem Solved!!

One point I failed to mention was that I'm doing this all in Hyper-V

I was checking the Hyper-V config for the internal Nic on the guest and by chance noticed an enabled feature in the advanced settings called DHCP guard. I disabled this and hey presto it's all working.

Hope this helps others!

... and thanks for all your inputs.