DHCP relay over TUN OpenVPN

  • Hello everyone,

    I'm trying to setup a DHCP relay from a remote site to our HQ which is hosting our DHCP server.
    The remote site is connected to our HQ using OpenVPN routed tunnels. A basic sketch would be:
    Client PC (waiting for DHCP) <-> Remote pfSense <-> VPN TUN <-> HQ pfSense <-> DHCP server
    I've investigated a little bit, and I found out that the DHCP relay daemon is supposed to listen on both the LAN interface (where it serves the DHCP requests) and the interface closest to the actual DHCP server (in my case, the TUN interface).
    I tried starting dhcrelay from CLI using the following command, but I get an error:

    /usr/local/sbin/dhcrelay -i ue0 -i ovpnc1 -d -a -m append -d
    --> Unsupported device type 23 for "ovpnc1"

    If I run the daemon only on the LAN interface, the Discover request does reach the DHCP server, but the Offer doesn't reach back the client.
    An option would be to use TAP interfaces insteaf of TUN, but that's something we'd like to avoid because of TAP drawbacks.

    Another option I've found is to use the package dhcprelya, which works really well but isn't integrated into pfSense GUI (and also not officialy supported).

    I'm wondering if there would be a possibility to include this package in future releases, and add a GUI for it, as it seems to work much better in my case (and I hope for others as well).
    And if someone has a shorter term solution for using the default DHCP relay with TUN interfaces, I'd very thankful!

    Thank you!

  • Netgate Administrator

    As you've found you can't use DHCP relay on an OpenVPN TUN interface. That's because it has no MAC address and dhcpd will only bind to interfaces with a MAC.
    As you also found you can use OpenVPN TAP and that's becaue they do have a MAC.

    What you can do here it use the TAP type OpenVPN interface but still route across it as though it was TUN.

    Change the adapter type to TAP at each end. Do not bridge anything. Then add the gateway back which isn't added by TAP, in the custom field:

    route-gateway x.x.x.x

    Where x.x.x.x is the opposite end tunnel IP. Restart the daemons.

    Check the dhcp logs to be sure the dhcrelay is now starting correctly.

    You may need additional firewall rules at each end if you don't have allow all rules.