dhcp-relay over OpenVPN-tunnel

[uhillebrand]

Hi,

we have a problem with DHCP-Relay over a OpenVPN-Tunnel.

We have a number of branch offices, which are connected to their (Windows-)Servers by OpenVPN-Tunnels. The clients in the branch offices are a mixture of laptops and thin clients. Until recently, a linux based firewall / vpn gateway did the site2site-vpn, filtering, and dhcp-relay to the domain controller using dnsmasq without problems.

We tried to migrate one branch office to OPNsense, and now have problems getting dhcp-relay to work. The dhcp-relay receives the DHCP request from the client, and forwards it correctly over the VPN tunnel to the domain controller. The reply (DHCP offer) is sucessfully sent back over the VPN tunnel (I see it with tcpdump), but then seems to get dropped. I do not see any blocked packets.

After researching I think I understand that dhcp-relay does not work on tun-adapters (which we have to use, we can´t use tap bridging in this case). So I guess I am out of luck using OPNsense´s dhcp-relay agent.

I tried to manually start dhcp-relay, and add the ovpn-Interface, but this leads to an "unspported interface"-error.

Does anyone see a potential workaround? I thought about enabling dnsmasq instead of unbound; but the dhcp-relay functionality is not exposed in the GUI. I am not sure if manually editing dnsmasq.conf is a good idea or could even work.

If we can´t make this work, we either have to swap the OPNsense with our linux router again, or run a dedicated linux box only for dnsmasq for dhcp relay.

Thanks in advance
Urban

[franco]

Hi,

How should broadcasting relay work on routed adapters like tun? What did the old Linux firewall use? It would indicate it did not use OpenVPN/tun?


Cheers,
Franco

[uhillebrand]

Correct my if I am wrong, but that´s what the dhcp relay agent is for, isn´t it? It´s located in the LAN, receives the broadcast, and relays it to the DHCP server (which is located in a different network).

That´s exactly how it worked with the old linux based router (iptables + OpenVPN + dnsmasq as relay agent - NOT as dhcp server). The VPN tunnel was routed via a tun interface as well.

Thanks
Urban

[franco]

Hmm, which actual error message did you see? And was it the GUI or dhcrelay binary? If it's a GUI limitation maybe the use case never came up before.


Cheers,
Franco

[uhillebrand]

Well, I might be barking up the wrong tree here.

After my clients did not get the DHCP offer (even if the DHCP server did send it), I thought the reason might be that I cannot select the ovpn-interface in the GUI for dhcp-relay, so the relay agent dismisses the offer.

Also, if I manually start

/usr/local/sbin/dhcrelay -i igb0 -i ovpnc1 10.248.0.64

.. i get:

Unsupported device type 23 for "ovpnc1"

After having re-read the dhcrelay-manpage, it seems like I only need to specify the interfaces where the agent listens to DHCP broadcasts, not (additionally) the interface where the answer is received. It makes perfectly sense that the tun-interface from OpenVPN is not able to receive a broadcast.

So my problem does not seem to be the dhcp-relay configuration, sorry for the confusion. My problem seems to be that the dhcp offer received on the tun-interface never reaches the client. I do not think the problem is with firewall rules, as I did not see any relevant blocked packets.

As it´s not possible to test this in the live network anymore, I will try to set up a test environment and will report back here. If you have a possible explanation for this behaviour, any ideas are welcome.

Thanks

[chemlud]

dhcp -> broadcast
tun -> no broadcast

try tap for openvpn -> broadcast

maybe?

[franco]

Looks like the outbound route isn't working in that case to 10.248.0.64. Try to see if traffic goes into ovpnc1 with tcpdump, or if maybe traffic goes out the default route (WAN).


Cheers,
Franco

[uhillebrand]

I apologize for the long delay, we could not test this again on this particular firewall. Today I am having the same problem with an identical setup - unfortunately we have to ship this firewall this evening, so I am unable to debug this further. With the current shortage of firewall hardware we are not able to set up a more permanent test environment for the time being.

Anyway, I tried to gather some more information.

The DHCP request is received on the LAN interface:

# tcpdump -ni igb0 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:03:53.391100 IP 10.0.192.2.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:c0:de:ca:fe, length 316

It is then sent on over the VPN tunnel to the DHCP-server by the relay agent, and is answered correctly:

# tcpdump -ni ovpnc2 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc2, link-type NULL (BSD loopback), capture size 262144 bytes
14:03:53.391159 IP 10.0.192.1.67 > 10.8.0.64.67: BOOTP/DHCP, Request from de:ad:c0:de:ca:fe, length 324
14:03:53.415025 IP 10.8.0.64.67 > 10.0.192.1.67: BOOTP/DHCP, Reply, length 320

If I check the answer packet with wireshark, I see only correct information there (ip, dns-servers, gateway, as configured on the DHCP server).

But this answer is then never forwarded back to the requesting client by the relay agent.

I do not see any blocked packets, and can´t seem to find a relevant log. Also, the dhcprelay-binary does not seem to offer more verbose logging or a debug mode.

Our current workaround is to use DHCP directly on the opnsense, but this is not a permanent solution. Any ideas would be welcome.

Thanks
Urban