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 10.100.94.203 -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.

    Steve



  • Thanks, this helped me out a lot when I could not get DHCP relay working over tun. Adding route-gateway to the OpenVPN setup did not work for me though, and neither does the "IPv4 Remote Network(s)" setting like it does with tun. After setting to tap I just added the gateway on each side to the opposite IP of the VPN subnet in System/Routing/Gateways, and then setup the static routes. After that everything routed properly, and DHCP relay works. I was afraid that by using tap I would get a bunch of broadcast traffic across the tunnel, but it doesn't seem to be an issue probably because I did not bridge interfaces.



  • @sparklan Hi sparklan. I'm in a situation similar to yours. Is there any way you could take the time to write out the details to this statement: " I just added the gateway on each side to the opposite IP of the VPN subnet in System/Routing/Gateways, and then setup the static routes." Could really ELI5 this? I switched to TAP to get DHCP over the tunnel, and that broke everything. I think the missing piece of my puzzle is in your sentence, but I don't know exactly how to put it together. Your time would be very much appreciated!!!

    Many thanks in advance.

    Cameron



  • @eidolontubes Example below...

    (LAN 192.168.1.0)---(Netgate OpenVPN Client TAP VPN IP 10.10.10.2)---Internet---(Netgate OpenVPN Server TAP VPN IP 10.10.10.1)---(Remote LAN 192.168.10.0 - DHCP Server 192.168.10.5)

    Leave "IPv4 Remote network(s)" blank in your OpenVPN config. Use system routing instead.

    On VPN Client side
    Create Gateway 10.10.10.1
    Create Route 192.168.10.0 -> 10.10.10.1
    DHCP Relay 192.168.10.5

    On VPN Server side
    Create Gateway 10.10.10.2
    Create Route 192.168.1.0 -> 10.10.10.2


Log in to reply