Showing results for 
Search instead for 
Did you mean: 

ASA NAT Public IP doesn't work

Level 1
Level 1


Here's the situation:  There is an ISP managed Fortinet firewall that this company uses..It currently is NAT'ing an internal Ip address (mail server) to a public ip address so that users can access their webmail over http from the outside.  Pretty straightforward.  Now, I've replaced this Fortinet device with a ASA 5505.  When I add the NAT translation on the ASA to the same public IP, it doesn't work.  It's as if the public IP doesn't exist.  No response to pings, nothing.  Now, if I experiment and translate the webmail's internal IP to a different public IP from our usable pool, it works fine, with no problems.  In fact, any of the usable public IPs can be NAT'ed just fine, except for the existing public IP that was in place with the Fortinet. Using the same public IP that was in place with the Fortinet, it doesn't work at all. 

Has anyone experienced this before?  What I'm wondering is if there is something that I need to do on the ISP side to remediate this?



5 Replies 5

Maykol Rojas
Cisco Employee
Cisco Employee

This is a pretty known "issue". The answer is reboot your ISP once you replace the Fortinet with the ASA.

The explanation: 

What happens is that the next hop has the mac address from the Fortinet associated with the public IP you are configuring on the ASA to do the NAT. On a normal scenario, the ASA should send a GARP (Gratuitous ARP) to the next hop saying that the NAT IP address should be mapped to the mac address of the ASA. This does not happen. 

So, the simple solution is to reboot the ISP device, that will flush the ARP table and when it comes up and somebody tries to send a packet to that host, an ARP request will be sent to the ASA and it will respond with its own mac address. The other, will be wait until the ARP cache expires, and there is a third one that I dont want to say.. cuz it can be a bit disruptive :). 

The fact that you say you use an unused IP address and it works, totally points me to the problem I stated. 

If you have question, let me know. 




Thanks, that totally makes sense, and I will give it a try the next time I am onsite.

What you just mentioned also got me thinking about perhaps another issue there that the ISP is affecting.  

When i put the ASA5505 in place of the Fortinet, the internal users on the corporate domain/LAN suddenly could not resolve DNS names.  I could ping the external ip addresses just fine, meaning outbound routing worked, but users could not resolve any domain names from their workstations.  Thus users could not browse the internet.  However, everything else within the firewall (aside from the NAT translation above), worked just fine.  My configuration of the ASA is the same as all my other clients, so I was kind of perplexed as to why it was happening when putting the ASA in place, yet, the Fortinet had no problems.  Putting the Fortinet back in place, suddenly DNS resolution works just fine.  

The internal clients are set to use the internal Windows DNS servers as their DNS servers.

Would you also attribute this to the ISP?



Hi Mooge,

Can you try to use the global DNS ( or in a test PC and check whether that resolves the issue or not. 

Since you are using the internal DNS server how does the traffic flow in ASA? Does the packet comes to say inside interface and forwards to the same interface? If the client and server are in the same subnet then the client should ARP for the DNS server and send the traffic directly to the server and there should not be any involvement of the firewall.

If the traffic comes to the ASA on say inside and sends out via the same interface then you need to have the command "same-security-traffic permit intra-interface"

You can also use the packet tracer to check what exactly is happening on the ASA if the DNS queries comes to the ASA.

packet-tracer input <interface name> udp <source ip> 1234  <DNS server iP> 53 detail

Shivapramod M
Please remember to select a correct answer and rate helpful posts

Thanks Shiva,

The clients and servers are on the same subnet.  The config of the asa is as follows below.  Fairly straightforward config.  My configuration for this ASA below is very similar to the dozens of clients that I have, and this is the first time I've seen this issue.  

ASA Version 8.2(5)
hostname asa
enable password encrypted
passwd encrypted
interface Ethernet0/0
 switchport access vlan 2
interface Ethernet0/1
interface Ethernet0/2
interface Ethernet0/3
interface Ethernet0/4
interface Ethernet0/5
interface Ethernet0/6
interface Ethernet0/7
interface Vlan1
 nameif inside
 security-level 100
 ip address
interface Vlan2
 nameif outside
 security-level 0
 ip address x.x.x.x
ftp mode passive
dns server-group DefaultDNS
access-list acl_out extended permit gre any any
access-list acl_out extended permit icmp any any
access-list acl_out extended permit icmp any any echo-reply
access-list acl_out extended permit gre any host x.x.x.149
access-list acl_out extended permit tcp any host x.x.x.147 eq https
access-list acl_out extended permit tcp any host x.x.x.147 eq www
access-list acl_out extended permit tcp any host x.x.x.149 eq pptp
access-list acl_out extended permit tcp any host x.x.x.150 eq 5900
access-list acl_out extended permit tcp any host x.x.x.150 eq 5901
access-list acl_out extended permit tcp any host x.x.x.150 eq https
pager lines 24
logging asdm informational
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdmfile
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1
static (inside,outside) x.x.x.147 netmask
static (inside,outside) x.x.x.149 netmask
static (inside,outside) x.x.x.150 netmask
access-group acl_out in interface outside
route outside x.x.x.145 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
telnet timeout 5
ssh inside
ssh x.x.x.x outside
ssh x.x.x.x outside
ssh timeout 60
console timeout 0

threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
class-map inspection_default
 match default-inspection-traffic
policy-map type inspect dns preset_dns_map
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect ip-options
service-policy global_policy global
prompt hostname context
no call-home reporting anonymous

Hi Mooge,

You can configure the command "same-security-traffic permit intra-interface" and test if it works if the DNS server is in the same subnet.

Ideally the ASA should not get the traffic. If you have a switch before the ASA then switch should forward the traffic to the server since the server and the PC are in the same subnet. If the DNS query comes to the firewall then the above command should resolve the issue.

Shivapramod M
Please remember to select a correct answer and rate helpful posts

Review Cisco Networking for a $25 gift card