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)?
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.
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.
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.
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.
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.
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.
ok happy to hear :)
If its not DNS, its asymmetric routing, if its not asymmetric routing its Hyper-V ;D
Good to hear you found the problem. I didn't even know There is such a options like DHCP Guard.
Regards,
S.
Quote from: Seimus on April 30, 2024, 09:07:07 PM
I didn't even know There is such a options like DHCP Guard.
Why not?
It is right in the GUI, well explained there and disabled by default.
Quote from: phwon on April 30, 2024, 05:19:27 PM
Hope this helps others!
I don't think so, it is kinda to obvious.
Quote from: Bob.Dig on April 30, 2024, 09:24:11 PM
Quote from: Seimus on April 30, 2024, 09:07:07 PM
I didn't even know There is such a options like DHCP Guard.
Why not?
It is right in the GUI, well explained there and disabled by default.
Because I don't use Hyper-V so I cant not know things about systems I do not use.
Regards,
S.
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).
This problem occurs only after 24.1.6.
- I am not using Hyper-V
- Everything is on physical devices.
- DHCP guard is not enabled.
- As a workaround, I have enabled DHCPv4 on Opnsense
Unfortunately I am also facing DHCP relay issues since updated to 24.1.6 - in earlier versions all worked as expected and I observed no issues.
Currently it seems that the DHCP relays suddenly stop to work and the clients are not longer able to receive DHCP addresses or renew the lease. Until lease expiry, the clients work as expected, but when the has expired, they are disconnected.
Also I am observing "BAD_ADDRESS" entries in the DHCP server, which I didn't notice before.
In some cases a restart of the DHCP relays solves the issue for some time, but not in every case.
Any suggestions if it is possible to log the activity of the relays? I did not find a regarding log yet.
I am using three DHCP relays to forward the DHCP requests of three subnets to one central DHCP server.
OPNsense is vitualized based on ESXi hypervisor - each OPNsense subnet uses its own virtual NIC provided by ESXi.
Any hints, how to enclose the issue are highly appreciated.
Many thanks in advance!
Best regards,
WM54
authelia and WM54
I appreciate the input, but can we avoid cluttering a topic that was solved by the original poster?
Open new threads please or find one that matches your problem.
Cheers,
Franco
Thanks for the hint - opened new thread.
Regards,
WM54
Quote from: Bob.Dig on April 30, 2024, 09:24:11 PM
Quote from: Seimus on April 30, 2024, 09:07:07 PM
I didn't even know There is such a options like DHCP Guard.
Why not?
It is right in the GUI, well explained there and disabled by default.
Quote from: phwon on April 30, 2024, 05:19:27 PM
Hope this helps others!
I don't think so, it is kinda to obvious.
There's always one! Top points for least valuable post of the day #yourock
Let's not trash on each other. It's obviously obvious in hindsight as that one saying goes. :)
But to be frank I think this thread will help a number of people in the future running into this problem so thanks for everyone involved.
Cheers,
Franco