ASA dhcprelay

[fosterl2]

I wish to configure dhcprelay on an ASA5505, where the DHCP server is found down the VPN tunnel. The normal config sends the relayed DHCP request outside of the tunnel, using the public IP address as the source, while I need it to be inside the tunnel, using the private IP address as the source.

Does anyone have any ideas?

Lee

[Ivan Martinon]

We can't change the behavior of which interface is going to be as the source of the relay, it will always be sent out via the interface where the server is located, in this case the outside interface. However by including this outside address as part of the crypto acl you can make sure this trafifc gets forwarded correctly when going to the dhcp server over the vpn tunnel.

[timothybward]

I'm dealing with this same issue. I'm still trying to get a handle conceptually on how this is working.

My setup is a headend 5520 and a remote 5505. Basically I'll have clients attached to the inside interface on the 5505 getting their dhcp addresses from a server that is located on the inside interface of the 5520. My understanding so far is that I need to configure the 5505.outside.ip to dhcp.server.ip in the crypto acl and then on the 5520 head configure dhcp.server.ip to 5520.outside.ip as part of my crypto acl. I have no idea if this is right and I sure would like some clarification if you get any.

Thanks!

Tim

[Ivan Martinon]

Tim,

Your idea is the right one, you need the public.ASA5505.Address to dchp.server.address on the crypto acl and the mirrored acl on the head end.

[timothybward]

Ivan,

Thank you for your reply. I'm going to try the install in the next hour or so. Thanks again!

[timothybward]

Works like a charm. Thanks!

[fosterl2]

I had been thinking that the ACL could be used to place the DHCP relay packets into the tunnel. The issue I then see is that the public IP address is the SA of the DHCP relay packet, which would not normally be routable through my core network (all private addressing), so I would have to add a static route at the headend to route the public address via the tunnel, as well as advertise it throughout the core.

What I had been considering to overcome this, is if I can NAT the SA at the remote end to one of my inside adddresses, then get the packet down the tunnel (can't seem to work that config out though). Alternatively, at the headend NAT the SA of the packet before putting it towards the core network. Are either of these feasable?

[Ivan Martinon]

Have never tried using nat with dhcp relay, but if you do not have the chance to use the routeable address of the remote asa then you might then use nat (again never used it) but in your case, the NAT will be performed on the head end, something called destination nat, make sure you use a policy in order to nat this ASA address only when going to the dhcp server or you might break your existing tunnel. something like this:

dhcp:192.168.1.10

ASA global: 66.66.66.66

Head end config might look like:

access-list dhcprelay permit ip host 66.66.66.66 host 192.168.1.10

static (outside,inside) 192.168.1.254 access-list dhcprelay

Make sure you use a non used inside address.

[fosterl2]

This is what the final outcome was: The remote DHCP server actually took the GIADDR from the relayed DHCP Discover and used that as the DA for the relayed DHCP Offer, thereby no SA NAT was required, as the response packet was not aimed at the originating public address, but a private address that could be passed down the IPSec tunnel. - Something to be aware of.

However, during the testing, I did get the SA NAT working for DHCP relay on the headend ASA, so if your DHCP server does not use the GIADDR as the DA of the DHCP Offer, this will be of use to You:

access-list extended permit ip any host

access-list extended permit ip host any

nat (outside) 1 access-list outside

global (inside) 1 interface

The "outside" keyword is required at the end of the nat command, as that instructs the box to allow translations from a lower security i/f to a higher one (this does not work with out it)

The command "global (inside) 1 interface" creates PAT using the IP address of the inside interface as the address that the SA is translated to, therefore there is no need to add any routes or use any other address.