Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Firewalls Community


Unexpected NAT results

Hi guys,

I'm hoping someone can help me with some unexpected results I recieved the other day. The firewall is running OS 9.1(1). I have 2 hosts off a DMZ interface. When I tried pinging from one host to another, I was getting an ARP response from the ASA. I disabled the NAT rules that affected the DMZ interface and everything worked fine again.

We use CSM to manage our ASAs, so have a lot of reusable object groups configured. A heirachy of our object groups looks as follows.

MPLS(Site(Site_LAN(, Site_DMZ(, Site_MPLS(

VPN(Site(Site_LAN(, Site_DMZ(, Site_MPLS(

The firewall has 4 interfaces configures, inside, outside, DMZ & MPLS.

As I have Dynamic PAT setup, to allow traffic from our VPN to the DMZ, I setup an identity NAT from the DMZ interface to the outside interface using the object group Site_DMZ as both sources and the object group VPN as both destination addresses with route lookup enabled.

This is obviously the issue, but if I have Dynamic PAT configured, how can I ensure my VPN traffic is not translated and the firewalls do not respond the ARPs for other hosts on the connected subnets?


Unexpected NAT results


There ASA might by default answer ARP queries if the Proxy ARP is not disabled on the interface.

The command format is

sysopt noproxyarp

I am not sure about how your NAT is setup. Would be easier for me to see the CLI format NAT configurations as I dont use ASDM or any other graphical interface to configure NAT,ACL,etc

- Jouni

Unexpected NAT results

Hi there.

Sorry it's taken me a while to get back.

I didn't want to globaly disable proxy ARP. This would have broken our ability to publish services. As we do not control the upstream router, removing proxy ARP would require configuring the correcty ARP on the upstream router or putting in routes.

Looking at the NAT command in the command reference, in OS version 8.4.2 & above, the behaviour has changed when using identity NAT. Between OS 8.3 & 8.4.1, the ASA does not proxy ARP responses for identity NAT rules, but does for all other rules. In 8.4.2 and above, the ASA always proxy ARPs unless the no-proxy-arp option is enabled.

See the third bullet point under Routing NAT Packets - Mapped Addresses and routing in the config guide.


Unexpected NAT results


Would really need to see some more information about the actual NAT configurations to be able to see how you have configured this.

I am a bit confused as you say in the original that you have Dynamic PAT for VPN to DMZ traffic. But you also say you have Identity NAT for the same traffic? Dont these rules conflict with eachother?

If you have some Dynamic NAT/PAT or Static NAT configurations from other interfaces towards the DMZ and they use the "interface" parameter and use the DMZ interface IP address as the NAT/PAT IP address then to my understanding Proxy ARP can be disabled on the DMZ interface so that the ASA doesnt answer to any ARP requests for IP addresses it doesnt own.

Even if the Proxy ARP was disabled globally on the DMZ interface it would still to my understanding mean that the ASA would reply to ARP request related to its interface IP address. Though this naturally makes sense as its acting as a gateway for the network so it must ATLEAST answer for request regarding the interface IP address.

- Jouni

Unexpected NAT results


I think 'something is being lost in translation'.

We have dynamic PAT setup, but not for traffic from the DMZ to the VPN. There's a comma there to separate the statements.

We wouldn't want to disable proxy arp on any of our interfaces as this will prevent us from publishing services from other intefaces onto that interface using IP addresses different to the interface IP address. We do not re-use the firewall interface IP address unless absolutely necessary.

Anyway, disabling the proxy ARP feature on the identity NAT rules, as discussed in the above link, solves the problem and enables us to publish other services on other IP addresses on that interface.

I think it was very bad practice of Cisco to make these changes to the way NAT worked. Especially in the middles of a software release train. You now have different command sets within the 8.4 software train, depending on when the software was released. I think I will be staying away from the 8.4 software train in the future. 8.3 or 9.0+.


Unexpected NAT results


Ah, read that part wrong then.

I would just be interested in seeing the problematic setup and its configurations cause I have not run into Proxy ARP related problems with any production environment or test setup I have done. (with multiple software levels)

Part of the reason why I participate here on the CSC is also see all these different problems people run into and learn from them and test them myself. So if its possible to share the configuration of the setup it would be great. If you dont want to share anything here you could naturally send me a private message through the profile. But naturally if this is something you cant/wont do, then no problem

As you say, there has been multiple changes to the NAT/ARP in the 8.4 and 9.x softwares and its really hard to keep track which software level had what changes.

Especially strange was the decision on software level 8.4(3) to disable the ability of ASA to populate its ARP table with nonconnected networks IP/MAC since I would imagine that its very common to have multiple public subnets on the WAN link of ASA. Ofcourse if this became a problem depends completely on how the ISP has handled the multiple public subnets. If they routed them towards ASA then naturally no ARP problems. If they used "secondary" networks on the gateway then essentially 8.4(3) broke connectivity for those additional networks. I dont think they even officially mentioned about this change which makes it even more wierd practice.

I became paranoid after that I am not even that sure about the 9.x software levels yet

- Jouni


Unexpected NAT results

Hi Christopher,

If i understood well than you want that your VPN traffic should not be translated. If that is the case you can do it with nat exemption.

Below is an example of how you can use nat exemption:-

ciscoasa(config)# access-list NAT_EXEMPT extended permit ip

ciscoasa(config)# nat (inside) 0 access-list NAT_EXEMPT


Bikas R. Pandey.


Unexpected NAT results

Hi Bikas,

That is old NAT format that wont work with the new 9.1 software.

The latest version where that is used is 8.2 software level

- Jouni