DHCP relay over IPSEC VPN?

Locutus · Jul 14, 2017, 11:44 AM

Hey everyone!

I'm a long-time user of pfSense (mostly on a virtual machine host), and have the following question:

I need to replace a hardware router (Netgear ProSafe) that's missing a feature required for its purpose: Sending DHCP relay packets through an IPSEC VPN tunnel while using VLANs.

The router is operating directly behind a DSL modem as primary router of two VLAN networks. One VLAN is a "classical on-site" network, router plays DHCP server, as Internet gateway for a number of PCs.

The router also establishes an IPSEC VPN to a remote site. A number of thin clients is connected to a second VLAN. That VLAN needs to operate in DHCP Relay mode. The DHCP server to forward requests to is reachable over the VPN (has a VPN IP).

The Netgear router does not support the latter: DHCP relay always gets forwarded through the public interface, and not through the VPN.

Can pfSense do better here? Does it forward DHCP relay packets through an IPSEC VPN tunnel if the relay target IP has an IP from the tunnel range?

jimp · Jul 17, 2017, 5:08 PM

No, it won't be able to properly relay DHCP across IPsec at this time.

The correct solution in either case is to configure DHCP relay on your switch instead. If it's a managed switch, it should support that either by the name DHCP Relay or perhaps "ip helper". If the switch performs the relay, the traffic can properly traverse the tunnel in either direction.

Quent-Un · Apr 18, 2018, 12:58 PM

Hi,
I'm currently use a pfsense to establish an IPSEC tunnel between A and B. The tunnel is established and all traffic from A go through this tunnel (the remote network B is declared as 0.0.0.0/0). My DHCP Server is at B site but when I try to use DHCP relay on the A site, the DHCP request isn't send inside the tunnel. How can I do that ?

Best regards

jimp · Apr 18, 2018, 1:01 PM

Read my last reply just above yours.

Quent-Un · Apr 18, 2018, 1:25 PM

So without another device it's impossible to do that ? Because before used pfSense I used a Cisco ASA and it worked fine.
Why the DHCP Discover isn't push inside the tunnel by pfSense ?

jimp · Apr 18, 2018, 1:31 PM

Because of the way the relay daemon works and how the packets are formed by the OS, it does not match the IPsec SA. It's probably trying to send it out a different interface.

You can try nudging it with a route but it's not likely to help for relay.

Quent-Un · Apr 18, 2018, 1:41 PM

I tryed to add a fake route to the LAN interface as written here : https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN but it doesn't work…

jimp · Apr 18, 2018, 1:43 PM

That's about all you can do at the OS level to nudge it the right way. IPsec, as it is at the moment, just can't deal well with that kind of traffic at the OS level. OpenVPN should work better, or move the relay job to an external device.

Eventually when IPsec virtual tunnel interfaces come around that might help, but it's still possible that something in the relay daemon might hold it back.

Quent-Un · Apr 18, 2018, 1:48 PM

I don't understand why some firewalls can do that and it's not possible on FreeBSD, it's the only thing which doesn't work, everything else works perfectly…
In this case I can't use OpenVPN.

jimp · Apr 18, 2018, 3:03 PM

Different operating systems, different IP stacks, different relay implementations, different IPsec implementations. You're comparing apples and oranges and wondering why the apple doesn't taste like an orange.

It doesn't work, so find an alternate solution (non-IPsec VPN, move the relay to a managed switch where it belongs, don't use relay, don't use pfSense for that specific VPN/relay, etc)

jlw52761 · Jan 17, 2020, 3:45 AM

I came across this while trying to setup a DHCP relay across my VTI IPSec tunnel, and I don't agree with jimp's answer. The reason is that basically what you are saying is that pfSense cannot pass a unicast packet across the IPSec tunnel. It does this regularly, so why wouldn't the DHCP Relay work since all it does is intercept the multicast broadcast from the client and convert it to a unicast packet.

I've been struggling with this and had some thought sessions with some network engineers who agree, there's no good reason pfSense cannot forward the unicast packet over the IPSec tunnel, just like any unicast packet that traverses all the time.

One thing that jimp says is to move the DHCP relay to a managed switch, which is what I will do once I have the final config for that done, but that's the same broadcast to unicast conversion, so why would one think that works from the managed switch unless the problem came from the way pfSense forms the packet and tries to route into the IPSec itself.

I'm really curious to understand this limitation more as just about every major firewall vendor out there, Cisco, Palo Alto, even VMware is able to do this, but pfSense can't? I mean how can I approach my management and tell them we should switch from Palo Alto to Netgate when we can't even perform this simple task that Palo Alto today does for us very well.

jimp · Jan 20, 2020, 2:55 PM

The limitation before was mostly due to IPsec in tunnel mode. In theory, VTI mode should handle it better, since you'd have proper OS routes to the destination. I haven't tried it, though. It might work, it might not, but if it doesn't work then it may be an issue in the DHCP relay daemon not wanting to latch onto the VTI interface itself. It's also possible that it's hitting an issue like https://redmine.pfsense.org/issues/9466 which may be solved on 2.4.5 which will be out soon.

Beyond that, it isn't necessarily about the type of packet but how it gets treated. Coming from the operating system on the firewall, it has different rules to follow vs a packet coming from the LAN. The OS has to follow its routing table when choosing not only where to deliver the packet but which source address to use. Because of that, the packets generated by the relay daemon may not match tunnel policies (in tunnel mode) thus would never be delivered to the far side.

jlw52761 · Jan 23, 2020, 3:31 AM

@jimp That makes much more sense, thank you for the expanded answer. I'm going to keep my eyes open for 2.4.5 and try the setup again, maybe they have it licked.

Mar 21, 2020, 8:52 AM

@jimp : DHCP Relay doesn't like VTIs as Upstream Interfaces:

Unsupported device type 131 for "ipsec1000"

Edit: Tested on 2.4.4-RELEASE-p3

rvoosterhout · Sep 14, 2022, 3:08 PM

We are 2 years further, is there any progress on relaying dhcp requests through an ipsec vpn tunnel?

maestrx · May 15, 2023, 8:25 PM

One year later and still hitting the same wall... any ideas with the 2.6.0 release ?

jlw52761 · May 23, 2023, 8:47 PM

@maestrx I get the feeling you will need to use your switch to do the DHCP relay functionality. I haven't done this on the pfSense platform, but I do this on my work's Palo Alto platform that uses IPSeC tunnels from remote sites to the main datacenter and DHCP is located centrally for the smaller sites. This is done using the Cisco ip-helper configuration of the SVI, but I bet other switches have this as well.

maestrx · May 23, 2023, 8:50 PM

@jlw52761 Thanks for your note. Our switches have L2 license only and the ones with L3 does not work with our usecase (PXE install) anyway. So we need to have it done on the FW level.

jlw52761 · May 23, 2023, 8:55 PM

@maestrx I don't understand your comment about L3 and PXEINSTALL. the ip-helper/DHCP Relay is all the switch has to do, which is essentially reflect the packets. The PXE is still handled by your DHCP server and the TFTP server.

maestrx · May 23, 2023, 8:59 PM

@jlw52761 Well, reality is showing that the ip-helper implementation in the switches is not perfect and the PXE boot usecase is not working for us. L2 switch means that the switch sees only up to the MAC address and does not see the content of the packets ( not able to distinguish if the packet is DHCP or any other type of traffic)