DHCP Relay through VPN (ISC DHCPv4)

[dennis_u]

Hey there,

we have to roll out a handful branch offices. There is nothing IT related stuff, clients only. They wish to control the clients from the DHCP server in the data center. I hardly try, but everytime I set a DHCP Relay IP, which is routed via VPN, it throws: "Unsupported device type 131 for "ipsec1"". If I take a DHCP server in "the internet" or locally, it works. I cannot see the purpose of an device type for an DHCP relay... 

The new KEA DHCP as alternative lacks the relay option or I cannot find it.

Do you have any idea?

[franco]

Hi,

Yes and no.

We're moving to OpenBSD's dhcrelay (the development version migration is done) which can theoretically handle layer 2 and layer 3 relay, but there are no plans to start dashing out layer 3 relay support in OPNsense. We did always require a layer 2 device to relay from.

Though what I don't understand is why you would select "ipsec1" for the relay. You want to relay a physical network to a server address routed somewhere, but not add a tunnel which doesn't have any directly attached clients?


Cheers,
Franco

[dennis_u]

Though what I don't understand is why you would select "ipsec1" for the relay. You want to relay a physical network to a server address routed somewhere, but not add a tunnel which doesn't have any directly attached clients?

To be more precise, I do not choose ipsec1, the OPNsense does. I choose "LAN" to listen to DHCP broadcasts, but a route lookup to the DHCP Server seems to yield ipsec1 as outgoing interface. ipsec1, by the way, is a route-based ESP tunnel interface. Maybe, it can try to change it to an policy based IPSEC tomorrow. The route lookup yields interface WAN in this case, which should be good for the relay. But I assume it is done for the source IP, which should not be the WAN IP in my case, but a local IP.

In general, it is a common requirement for small offices to catch DHCP requests on LAN side and send it through a VPN tunnel to a central DHCP server.

In the worst case I have to install RPis in the local networks with an ISC DHCP to relay through the tunnel.

[franco]

Fair enough, thanks for explaining.

The auto-select of bad interfaces was fixed in 24.1.4 today actually... and on the new DHCRelay implementation it doesn't exist at all anymore. You just chose the interface to relay from and the server destination IP(s).

According to a customer this works even better than the ISC relay. And the nicest thing is you can now (as in "development release") run DHCP server and relay in tandem.


Cheers,
Franco

[allan]

According to a customer this works even better than the ISC relay. And the nicest thing is you can now (as in "development release") run DHCP server and relay in tandem.

Gentlemen you had my curiosity ... but now you have my attention.

Thanks franco and team!

[franco]

Happy little accident I suppose. 


Cheers,
Franco

[dennis_u]

Status update:

Indeed, with the last revision (24.1.4, 31cd002eb), there is no error with DHCP relay through VPN tunnels, but: it is not working. I assume that it sends the requests with the virtual tunnel IP (couldn't troubleshoot this branch office any more). The current workaround is a local DHCP server. I'm doing more tests with the next branch office.

On the long run, I'm looking forward to 24.7 with the new implementation. In case of pre-production tests, I have to change the software channel to type=Development in the WebGUI, right?

Thanks team for your excellent work.

[franco]

> there is no error with DHCP relay through VPN tunnels, but: it is not working

Sounds exactly like the issue the customer had.

> On the long run, I'm looking forward to 24.7 with the new implementation. In case of pre-production tests, I have to change the software channel to type=Development in the WebGUI, right?

Yes, but keep in mind that the move to the new DHCRelay will move the configuration to the new format so going back to the stable version will have the old configuration missing. The backwards compatibility was not aimed for here for related reasons like the new OpenBSD dhcrelay working a bit differently from the command line.

I need to talk internally about the backport strategy as this is mostly a drop-in replacement but we have to consider the risks. This may be material for 24.1.x but I can't make any promises for now.

Of course real world feedback would always help speed this process up.


Cheers,
Franco