Can I configure an ASA5505 to listen to relayed DHCP requests.

[tdennehy]

I'll start out with the fact I work mostly with Wi-Fi and not a lot in the security realm... so please pardon my ignorance for a few moments...

Here's my setup:

ASA5505  ---------------- WS-C3560 --------tagged----------WLC2106  -------------------------------AIR-LAP1142------------------wireless laptop client

(DHCP SERVER)           (simple config)          (dhcp proxy disabled)           (is requesting dhcp from ASA)

If I plug my workstation into the 3560, my wired client adapter can get an IP address.  But the WLAN adapter will not when associated to WLAN.

Usually this is not a problem since you may only have two access points on the controller and a dozen or so hosts.  In my case, however, I want to put a few of the ports on the 3560 into the same VLAN as the WLAN on the 2106 so I can give them the same guest access as the WLAN.  The hosts plugged into the 3560 get an IP address without issue from the ASA.  When I disable dhcp proxy, the WLAN clients get an IP address, but then the APs cannot get an IP address from the internal DHCP server on the WLAN controller, and  cease to function when rebooted since they cannot get to the controller without an IP address.

Anyone know if there is a way to configure the ASA to accept the modified DHCP packets from the WLAN controller?  It appears to me that the ASA is not able to accept DHCP relayed packets...

Thanks in advance...

[Jouni Forss]

Hi,

You sure that it was not some old binding left on the switch?

Basically the only time I have used this in a production enviroment was this.

• The customer had xDSL connections from us to 2 different sites
• These connections were taken as L2 all the way to our Multiple Context Mode FWSM inside a single Security Context
• The Security Context had an "outside" interface and the 2 "inside" interfaces named based on their location
• One of the sites had originally its own DHCP server
• Other site for some time was using staticly configured IP addresses on the hosts
• They wanted to start using the other sites DHCP server for the previously staticly configured site
• We configure the DHCP Relay between these FWSM interfaces and they were able to use the other sites DHCP server for both of their sites

I guess the simplest way to test if DHCP Relay was working would be to attach 2 hosts to the ASA5505. One on the "management" and one on the "inside" interface. Configure the DHCP Relay just like you have. Configure the other host as DHCP server (or even use a network device as the DHCP server). And configure the "inside" host to use DHCP to aquire IP address.

Then you could first test if it works.

If it doesnt then you can either try to use the debug commands to define what the problem is

debug dhcprelay event

debug dhcprelay packet

debug dhcprelay error

Or you could do the traffic/packet capture on the ASA to see if traffic is actually leaving the "management" interface for the DHCP server and if anything is coming back.

- Jouni

[tdennehy]

Yes, I am sure it was not an old binding, unfortunately.  I cleared the bindings several times just to prove I am clinically insane and should be commited.

I think next week (today is Friday for me) I am doing to do exactly what you just stated.  Use my laptop host to get on outside switch where I have the dummy dhcp scope and test to make sure I get an address.  Then move it closer to the ASA, then inside the ASA and see if it works.  Then move the dhcp server/switch "away" from the ASA and see where it breaks.

I am starting to think you are correct about not having a route back.  The routing resource was not available this week..

I think that I don't fully understand the difference between ping and dhcp.  If my management interface can ping and traceroute to the production dhcp, then why can't a dhcp packet find its way to the dhcp server and then back again.

Thanks for all your help so far.  I'll know more next week.  It is time for me to head out...for a well-deserved three day weekend...

[Jouni Forss]

Hi,

If you are talking about sending ICMP Echo from the ASA directly to the DHCP server then this will naturally work as ASA will source the ICMP with its "management" interface IP address. And since this interface IP address is part of a link network between some production device and the ASA then naturally the production network device sees the network as directly connected and has a return route for the ICMP Echo-reply back to the ASA "management" interface.

However, if the ASA is acting as a DHCP Relay then it will probably send the unicast DHCP messages with a source address of the "inside" interface IP address, NOT the management.

To my understanding this works the same way with Cisco router and "ip helper-address" configuration. The unicast DHCP messages are source with the IP address of the interface where the "ip helper-address" is configured in. This could be compared with the "dhcprelay enable inside" which uses the "inside" interface of the ASA.

So this is why I think you need to have a return route for the ASA "inside" network from the DHCP server.

- Jouni

[tdennehy]

I believe you are correct about everything.  I believe the initial discovery packet is hitting the dhcp server since it is sourced from the ASA's inside interface, and the configuration points to the dhcp server with the dhcprelay command out the management interface.  So the dhcp server gets the first packet and replies, but the network doesn't know what to do with it.

The management interface of the ASA is on the same network as all the switches' management interfaces.  The interfaces we SSH to in order to configure the switches - so no other users/hosts are on it.  That was the logical place to connect the management interface of the ASA.

When I SSH to the core switch and issue "sho ip route", I do not have a route to the 192.168.57.0/24 network in the list because the network does not know about it.

I tried to put an ip helper-address on the management SVI of the core switch pointing to the DHCP server, and of course, that did not work since I did not configure the dhcprelay command to go to the SVI.  I still think it would not have worked because the source was the inside interface of the ASA.

Now that I know I have to put an ip route on the core switch - I am not sure where to point the route.  If my inside interface is ip address 192.168.57.1/24 and my management ip address 10.47.240.225/24, do you know if I point the ip route to the management host address, or just to the management network itself?

ip route 192.168.57.0 255.255.255.0 10.47.240.225

or

ip route 192.168.57.0 255.255.255.0 10.47.240.0

Again, thanks for all your help!

[Jouni Forss · Accepted solution]

Hi,

You would configure the static route for the "inside" network to point to the Interface IP address of "management" on the ASA. As that is the next hop towards the "inside" network. I would suggest that just to be thorough, you go through the routing all the way from the DHCP server to the ASA so that you know that the routing is fine.

As I said before I have only used this in the environment with 2 customer xDSL sites connected L2 to the same firewall. This already meant that everything worked wihtout adding any routes as the return traffic always found its way to the firewall (DHCP servers default gateway = firewall interface IP address) and from there back to the host asking for the IP address.

I hope the information has indeed helped.

You can naturally rate the answer(s) if you have felt them to be of help. Thats the best way to encourage people to keep on helping and answering here on the forums. Naturally if at some point you feel that you have gotten the correct answer that solved the original question, please mark that question as the correct answer at the bottom of that reply.

Naturally you can ask more if needed. Will try to answer if I can.

- Jouni

[tdennehy]

Thanks for the help!  The static route was the problem all along!

[Jouni Forss]

Hi,

Glad to hear its working

- Jouni