cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1711
Views
0
Helpful
3
Replies

ASA - DHCP relay through 2 different asa boxes.

Kent Heide
Level 1
Level 1

Hey,

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.

ASA5505

inside: 192.168.113.0/24

outside: 192.168.254.28/30 (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.

192.168.254.30(67) -> 192.168.100.13(67)

The return packet looks like this:

192.168.100.13(67) -> 192.168.113.1(67)


AFAIK the return packet should go to 192.168.254.30 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?

3 Replies 3

Kureli Sankar
Cisco Employee
Cisco Employee

Kent,

I believe what you are seeing is expected.

client ----(192.168.113.1/IN)ASA(OUT/192.168.254.30)-----Server 192.168.100.13

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.

192.168.254.30(67) -> 192.168.100.13(67)

The return packet looks like this:

192.168.100.13(67) -> 192.168.113.1(67)

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:

http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=view&target=dhcp.pcap

-KS

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?

Kent,

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.

-KS

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card