DHCP Relay in a Wireguard Tunnel

Hi Everyone.

Hope you can help me with lab issue. I setup a lab with 2 pfsense configured to have a site to site wireguard vpn. The tunnel works computers in site A can talk to computer site B via ICMP. The only issue is, I setup a DC in Site A with DHCP and there is a DHCP client computer in site B. DHCP client cannot receive any DHCP IP. If I move DHCP client into site A but on a different VLAN, DHCP relay works on that separate VLAN.

My question is, does Wireguard allows DHCP relay to traverse?

Wireguard isn’t the one supporting DHCP relay. Wireguard just sets up an interface and adds the basic routing tables. From what I understand to get this to work you would need to setup DHCP Relay on the DHCP server in pfsense on site B. I’ve not done this on pfsense but I am sure it is possible.

It has been a few years since I admin’ed a DC, but I didn’t have my DC doing DHCP. DNS was the big stickler for DC from what I remember. For that I had my DNS zone forward all ad.xxx.com lookups to the DC nameserver.

Make you life easy,

Setup dhcp on site B, with the dns server settings pointing to your domain controller.

Then setup active directory site and subnets for network on site b

2 Likes

Thanks for your reply, my apologies I have used the wrong term. I have corrected my earlier post. Thanks also for confirming that the setup I am doing in the lab is possible.

I am doing this just to learn and experience possible scenario. My main goal is try all possible scenario in the lab experience, try to figure, make mistake, correct mistake and ask smarter people like you if they have experience this or not.

In regards to my issue, I have checked the dhcp logs on my pfsense and this is what I got:

|Aug 18 20:20:51|dhcrelay|52105|process and the information we find helpful for debugging.|
|---|---|---|---|
|Aug 18 20:20:51|dhcrelay|52105|before submitting a bug. These pages explain the proper|
|Aug 18 20:20:51|dhcrelay|52105|bugs on either our web page at www.isc.org or in the README file|
|Aug 18 20:20:51|dhcrelay|52105|than a configuration issue please read the section on submitting|
|Aug 18 20:20:51|dhcrelay|52105|If you think you have received this message due to a bug rather|
|Aug 18 20:20:51|dhcrelay|52105|Unsupported device type 248 for tun_wg0|
|Aug 18 20:20:51|dhcrelay|52105|Sending on BPF/xn1/4e:4b:b1:08:e4:6f|
|Aug 18 20:20:51|dhcrelay|52105|Listening on BPF/xn1/4e:4b:b1:08:e4:6f|
|Aug 18 20:20:51|dhcrelay|52105|For info, please visit https://www.isc.org/software/dhcp/|
|Aug 18 20:20:51|dhcrelay|52105|All rights reserved.|
|Aug 18 20:20:51|dhcrelay|52105|Copyright 2004-2022 Internet Systems Consortium.|
|Aug 18 20:20:51|dhcrelay|52105|Internet Systems Consortium DHCP Relay Agent 4.4.3-P1|

I may need to submit this to Netgate forum just to confirm if it is bug or relay would not work with Wireguard site to site tunnel.

DHCP is a broadcast protocol, so it works only within a broadcast domain aka network, subnet or (wrongly) “VLAN”. A DHCP relay service functions by capturing DHCP messages on one network and re-transmitting them on another network. Since the server and client exchange messages back and forth, the DHCP relay has to work in both directions. So for DHCP relay to work over a VPN, you would need 2 additional components:

  1. A VPN that understands DHCP so it knows what to do with broadcast packets.
  2. A second relay on the remote side of the tunnel that relays the clients’ responses back to the DHCP server on the main site.

With normal interfaces, the relay service will just put the packets on the wire and the switches take care of delivering them to the correct recipient. VPN interfaces work differently, though. If the Wireguard service were to receive relayed broadcast packets on its virtual interface, it would most likely discard them as it doesn’t know where to forward them to. But from your logs it seems they don’t even make it that far since the relay service doesn’t support tunnel interfaces in the first place:

I just happen to be messing around with dhcp relay in Kea (the isc-dhcpd replacement) and did see an option in the config to relay UDP packets only. This would keep the source DHCP server from having to listen for raw sockets. Not sure if the older isc-dhcp server in pfsense has this option too, but if so it would allow you to relay through the wiregard interface.

From what I gather, pfsense does not have an ETA when they will migrate off the old dhcp server that is EOL as of January. Which is concerning given it runs as root. Actually, running all this stuff as root concerns me. But that is just me.

Back to your setup, I would consider abandoning the need to run DHCP on your DC if possible. If not I would like to know why.

Back to your setup, I would consider abandoning the need to run DHCP on your DC if possible. If not I would like to know why.

My reason are:

  1. My goal for this lab is setup a 2 sites with wireguard vpn
  2. Have Windows server acting as DC, DNS and DHCP server and a client computer at Site B
  3. Make DHCP relay work on pfsense for both site.
  4. I am not that good with Linux, still trying to learn I have good experience with Windows. Trying to learn both Linux and Windows. Probably my next lab would be something similar but using Linux OS

Well, if those are the marching orders then you’ll need to install Kea in a container or VM and setup dhcp relay with that UDP setting. I got it working for the basic setup but was having issues with static IP assignments. I abandoned the relay config because I realized I didn’t care enough to see it all the way through… and other reasons.

What is Kea? This is the first time I heard about Kea.

If you are asking that question at this point in the conversation then you should hire this out or change your requirements. Just set up dhcp on pfsnese like the previous poster suggested. That is the path of least resistance. You’ll have a hard time finding an MSP that will admin by keyboard.

I was just asking what is Kea because this is the first time I heard of it. I have no intention of using it at this moment. Anyways thanks for the response.