11-27-2009 04:24 AM - edited 03-11-2019 09:43 AM
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?
11-29-2009 09:15 AM
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
11-30-2009 12:10 AM
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?
11-30-2009 06:30 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide