ASA - DHCP relay through 2 different asa boxes.

Unanswered Question
Nov 27th, 2009


I have a remote location ASA5505 which is connected through an IPVPN/MPLS backbone to an ASA5520. Behind the 5520 lies the DHCP server.

When I debug and use capture I can see the unicast packets from the DHCP relay agent on the 5505 all the way through the 5520 and exiting out the interface towards the DHCP server.



outside: (with .30 as the ip on the interface)

Config on the 5520 is irrelevant, but there are no rules blocking the traffic.

The packet towards the server looks like this. ->

The return packet looks like this: ->

AFAIK the return packet should go to which is the source. I can imagine the dhcprelay agent on the 5505 is becoming confused when the reply is sent to a different address.

Any ideas?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Kureli Sankar Sun, 11/29/2009 - 09:15


I believe what you are seeing is expected.

client ----(

I just looked at an old capture that I had.

Offer comes from the server with the server's IP as the source and the destination IP of the relay agent's IP which was inside the previous discover packet.

This offer gets sent to the client with the source IP of the relay agent IP.

The following you observed is correct. I am assuming that is the capture taken on the outside interface on the FW.

The packet towards the server looks like this. ->

The return packet looks like this: ->

Collect simultaneous captures on the ASA on both the inside and outside interface and observe the relay agent IP on the discover packet egressing the outside interface. The offer will be destined to the relay agent's IP seen in the discover packet.

You can see sample captures here:


Kent Heide Mon, 11/30/2009 - 00:10

I have looked at your pcap. I don't see how I would make it work still.

I have investigated it so far that I can see the packets disappearing on the FW when the packets return from the server. I would see this being normal if this was TCP because there is no session/connection that matches it. But this is UDP, why would the FW drop it on the return?

Kureli Sankar Mon, 11/30/2009 - 06:30


I'd suggest to look at the following:

1. logs

2. captures - both ingress and egress

3. sh asp drop (after issuing "clear asp drop"

4. you can also collect asp drop captures "cap capdrop type asp-drop all" then issue sh cap capasp" to see if the IP address of interest in in there.

5. debug dhcp event/packet/error and see what might be causing these packets reach the client.



This Discussion

Related Content