DHCP relay on Cisco ASA over an IPsec tunnel

[Rudresh Veerappaji]

• Introduction
• Resolution

Introduction

Consider a scenario wherein we need to configure PIX as a DHCP relay so that clients behind  the PIX could get IP addresses from

a DHCP server which is behind a headend ASA. The ASA and the  PIX are the VPN terminating devices.

Brief topology:

Remote Site 1                               Remote site2

clients---PIX <--> <IP sec tunnel> ASA----DHCP server

Resolution

To resolve the issue, we need to use DHCP relay configuration on the PIX which is as follows:

Pix(config)# dhcprelay server <ip address of DHCP server >outside

Pix(config)# dhcprelay enable inside

--We need to add two more entries in the crypto access-list for DHCP request and reply to traverse over the Ipsec tunnel, along with the usual crypto acls for local and remote subnets.

1.  An entry with source ip as the outside interface of the PIX and the destination ip as the IP address of the DHCP server which is on the other end.

2.  Another entry with source ip as the ip of the client interface of the PIX and the destination as the ip addres of the DHCP server.

The first entry is for the DHCP request to go over the tunnel, the second entry is for the DHCP reply which is sent to the client interface and not the outside interface of the PIX. It is very important to note that the DHCP Server will reply to the address of the interface through which the DHCP Discover message came. Also, at the ASA end, it has to be made sure that the traffic from the DHCP server to the client interface of the PIX is excluded from being natted by the ASA.

The DHCP message exchange is elaborated in the diagram attached with the post

(Here the ASA is acting as the DHCP relay agent.)

It should be working fine with the above configuration.

Cheers,

Rudresh V

[gp1200x]

I have this working and it works great. It can only be used with ASA/PIX devices that use a static IP address on the outside interface since you have to code that into the ACL crypto statement. I used it with a site that created dynamic ACLs at the main site when it connects and it worked correctly. I have not figured out if there is any way to use with with sites that have a dynamic IP - I don't think there is. This was an excellent writeup by the author.

In conclusion he said:

1. The remote site needs an ACL statement for the crypto map which encrypts the data from the outside PIX/ASA interface to the DHCP server(s). Create a matching one on the host end if you are not using dynamic cryptos.

2. The remote site needs an ACL statement for the crypto map which encrypts data from the inside interface of the PIX/ASA to the DHCP server(s). Note that this is usually already encompassed in the basic network to network ACL crypto statements.

3. There cannot be any natting between the DHCP server(s) and the inside interface of the PIX/ASA and subnet clients requesting addressses. (I believe this to the the case and it is how I always configure remote sites anyway).

4. The statements "dhcprelay enable inside" and "dhcprelay server x.x.x.x outside" are needed in the config.

Real time saver compared to the setups some others suggested on this site. This works at multiple locations I have with never any issues. I also use an "ntp server x.x.x.x source inside prefer" to always keep my tunnels active for both static IP sites and dynamic IP sites with x.x.x.x being an address at the main host site.

[gp1200x]

Good solution above...a few other sites I simply used a L3 switch at the remote site to act as a relay and in that case no ACLs or any changes are usually required if no natting takes place between the subnets and dhcp servers. Unfortunately the ASA cannot turn on DHCPD and DHCP-RELAY simultaneously which causes a solution problem at some of my sites and requires and additional piece of hardware to resolve. Ex - using DHCPD on the DMZ for wireless users  and trying to use dhcp-relay for the inside users.  

[bbiandov]

I can confirm that the 2 (just TWO) CLI commands make all of this work, prerequisite being that the IPsec tunnel passes non-NAT traffic between the two sites which I assume is pretty much the general case if anyone is looking to do that we're discussing here

Pix(config)# dhcprelay server 192.168.155.201 outside

Pix(config)# dhcprelay enable inside

~B