09-19-2017 01:37 PM - edited 02-21-2020 06:20 AM
Upgrading from PIX (6.3) to an ASA 5515 (9.4). Went to make switch other day, and had to backout due to a specific application inside the DMZ not being able to reach an outside destination host. Here is scenario:
Src Host 172.16.10.10 behind DMZ interface (sec level 50)
Dst Host 192.168.1.1 behind Outside interface (sec level 0)
Src host get's NAT'd to 10.1.1.1 when sending traffic outside. Below is statement on ASA firewall for the NAT
nat (DMZ,Outside source static OBJ-172.16.10.10 OBJ-10.1.1.1
Packet capture taken on ingress and egress interface shows packet entering and leaving, shows the correct src NAT address on its way out the egress interface; shown below
10.1.1.1.51801 > 192.168.1.1.5631: S
10.1.1.1.51801 > 192.168.1.1.5631: S
10.1.1.1.51801 > 192.168.1.1.5631: S
I see no response from the server. As soon as I put PIX back in place, it starts working. The PIX NAT looks like this:
static (DMZ,Outside) 10.1.1.1 172.16.10.10 netmask 255.255.255.255 0 0
Connection and XLATE table on PIX look like this when the connection is successful:
LabFW1(config)# sh conn
1 in use, 1 most used
TCP out 192.168.1.1:5631 in 172.16.10.10:51806 idle 0:00:00 Bytes 99541 flags UIO
WMOTFPPLabFW1(config)# sh xlate
1 in use, 1 most used
Global 10.1.1.1 Local 172.16.10.10
****************************************
Any idea what would make no return traffic? would proxy arp have anything to do with this? I took the existing static commands from my PIX and ran them through an online converter tool when I built the ASA config, but noticed it didn't append the statements with "no-proxy-arp route-lookup" as I've since seen on some other NAT statements. Would the absense of those keywords have anything to do with no return traffic? Routing is good, I can ping the gateway, just seems tied to this DMZ computer that gets NATd. Not quite clear on what, if any, difference there is in a NAT statement with vs without those appended keywords.
any help appreciated!
09-19-2017 02:46 PM
Hi mjsully,
Your configurtion on ASA looks good. It seems that host 192.168.1.1 has an ARP issue. Have you tried to refresh the ARP table of host 192.168.1.1?
09-19-2017 03:44 PM
thanks for the reply. I don't think the remote host has the arp issue. I failed to mentiion that the remote host 192.168.1.1 is NOT located locally to the ASA's outside interface. In other words, its a remote network that the ASA only reaches by sending to a specific route for that network. So I believe the only arp involved for the remote host would involve its gateway back to the ASA. But I'm wondering if there is an arp issue on a device in between that has the MAC of the old PIX for the SRC NAT, but I'm not 100% sure on how that works which is why I am posing the question about whether or not my NAT statements make the NAT behave different if I don't have the no-proxy-arp route-lookup keywords.
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