- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: DHCP Relay over Site-to-Site VPN
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
DHCP Relay over Site-to-Site VPN
Hi Checkmates,
I’ve recently setup a Site-to-Site VPN link between our head office and a remote office that will shortly be opened. The VPN link is stable and works as expected, but I’m having trouble DHCP relaying for the remote site. The remote site is quite small, so I want to use the DHCP servers in the head office for IP address leases.
Is there a guide that explains how to configure DHCP relay across a site-to-site VPN?
We have multiple VLANS in the head office, DHCP relay is enabled on the gateways and it works flawlessly.
Any help, pointers greatly appreciated.
PS. I have already configured DHCP relay on the remote gateway and added firewall rules as per sk104114.
PSS. Overview diagram of infrastructure is below.
Thank you.
.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can't say that I have ever set something like this up, but the instructions to do this with embedded Gaia firewalls is described here:
sk107097: Configuring DHCP relay through Site-to-Site VPN on GAIA embedded Appliances
Also be sure to follow all steps precisely as shown in this SK, as it is a rather lengthy setup:
sk104114: Configuration of IPv4 BOOTP/DHCP Relay using new services
If I'm reading that first SK correctly, for your 5500 firewall you may need a manual NAT rule that ensures the initial DHCP Request is source NATted to the internal IP address of your 5500 on the interface where the DHCP request came in. This internal IP Address must be contained within the 5500 firewall's VPN domain, which therefore will get encrypted into the tunnel to HQ assuming DHCP Relay is properly configured in the Gaia OS of the 5500. Setting the primary address in the DHCP Relay setup to the inside address of the 5500 may do the trick as well.
This NAT setup should be the equivalent of the "use internal IP as source" checkbox mentioned in the first SK, although the fwx_dhcp_relay_nat variable in the second SK might take care of this for you, not sure.
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've got DHCP working across VPN, not really seen any issues with this other then on odd occasion rule reordering made it work.
Ensure on your remote gateway you have actually setup a relay, ensure the encryption domain contains the remote gateway and subnets.
As Tim mentions below ensure fwx_dhcp_relay_nat is set to 1 (I think this is only required if your using legacy DHCP)
Ensure your routing is correct.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can't say that I have ever set something like this up, but the instructions to do this with embedded Gaia firewalls is described here:
sk107097: Configuring DHCP relay through Site-to-Site VPN on GAIA embedded Appliances
Also be sure to follow all steps precisely as shown in this SK, as it is a rather lengthy setup:
sk104114: Configuration of IPv4 BOOTP/DHCP Relay using new services
If I'm reading that first SK correctly, for your 5500 firewall you may need a manual NAT rule that ensures the initial DHCP Request is source NATted to the internal IP address of your 5500 on the interface where the DHCP request came in. This internal IP Address must be contained within the 5500 firewall's VPN domain, which therefore will get encrypted into the tunnel to HQ assuming DHCP Relay is properly configured in the Gaia OS of the 5500. Setting the primary address in the DHCP Relay setup to the inside address of the 5500 may do the trick as well.
This NAT setup should be the equivalent of the "use internal IP as source" checkbox mentioned in the first SK, although the fwx_dhcp_relay_nat variable in the second SK might take care of this for you, not sure.
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've got DHCP working across VPN, not really seen any issues with this other then on odd occasion rule reordering made it work.
Ensure on your remote gateway you have actually setup a relay, ensure the encryption domain contains the remote gateway and subnets.
As Tim mentions below ensure fwx_dhcp_relay_nat is set to 1 (I think this is only required if your using legacy DHCP)
Ensure your routing is correct.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I realise this is a slightly old thread now, but thought it worth adding my recent experiences on this front.
With much the same topology as the original poster, except in our scenario there was DHCP relay was already set up and working at the branch office (3800 HA pair) to a local DHCP server on a different subnet, and the on site DHCP server was being removed, forcing the shift to use the DHCP server on the other end of the site-to-site VPN (via 6600 HA pair).
The key parameter does appear to be making sure fwx_dhcp_relay_nat is set to 1 - the sk implies that this is for R77.x, and isn't needed from R80.10 onwards, or with the new DHCP services, but it appears to be necessary. (This was on R80.40, with new DHCP services).
