DHCP relay over IPsec not giving replies

rlu

Hey there,

I'm desperately trying to get DHCP relay to work over an IPsec tunnel (site-to-site). I have tried to achieve that on versions 2.1.5, 2.2.3 and now 2.2.4, yet it won't work properly. To make things easier, this will give you an idea of how my current setup looks like:


      .------------.
      | DHCP Client| 
      '-----+------'
            |
      LAN B | 192.168.1.0/24
            |
      .-----+-----.
      |  pfSense2 | 
      '-----+-----' 62.55.44.22 (anonymized)
            |
        WAN | IPsec tunnel
            |
      .-----+-----. 66.55.44.33 (anonymized)
      |  pfSense1 |
      '-----+-----'
            |
      LAN A | 192.168.3.0/24
            |
      .-----+------.
      | DHCP Server| 192.168.3.4
      '------------'

The pfSense1 is configured to relay DHCP requests to the DHCP server at 192.168.3.4 (remote end of the IPsec tunnel). Both pfSenses are configured to pass any traffic that goes through the tunnel. The tunnel itself is created using default values only except the remote gateway, remote network and no encryption (AH instead of ESP) to better monitor what's going on.

With the use of this workaround I managed to get the DHCP requests to the server and replies back into the tunnel. Sadly that's already as far as it goes; the DHCP reply never seems to leave the DHCP tunnel again at pfSense2 and thus never reaches the 192.168.1.0 net where the initial request originates from.

Similar problems have been posted on here, I did not find a working solution however :(
Any ideas?

rlu

Little update:

I got it working by replacing pfSense 2 (where the DHCP reply got lost in the tunnel) with a non-pfSense box. However this is just a workaround and I'd like to get it running using pfSense.

Can someone please tell me how to get the DHCP reply back out of the IPsec tunnel? If not, is this a bug and will it get fixed (soon) ?

cmb

Likely:
https://doc.pfsense.org/index.php/Why_can't_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN

with the appropriate route, that should work.

Generally speaking, it's probably not a great idea to rely on a remote site over VPN for your DHCP, unless in a scenario where that entire network is dead anyway if the remote site is unavailable.

rlu

Thanks for that hint, I already did that and managed to get DHCP relay into the tunnel (without that workaround it refused to send the paket into the tunnel and showed up something like 'no route to host' in DHCP-logs). With the route from the workaround you suggested I managed to get the request out to the DHCP server, but it refuses to re-enter the pfSense it originated from.
As a workaround for this I took another pfSense behind the pfSense (which was intended to to the relay in the first place) as LAN-B-client-only doing the relay instead of pfSense2. This worked without any problems. It's just the need of a third machine doing the relay since it refuses to work on the same one that is the end of an IPsec tunnel.

@cmb:

[…]it's probably not a great idea to rely on a remote site over VPN for your DHCP, unless in a scenario where that entire network is dead anyway if the remote site is unavailable.

I totally agree; that's what I'm thinking too, however I'm being told to get this working exactly this way, no matter what problems it brings.

Thanks for your help ^.^