12-11-2015 10:20 AM - edited 03-12-2019 12:01 AM
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?
12-11-2015 06:46 PM
This is a pretty known "issue". The answer is reboot your ISP once you replace the Fortinet with the ASA.
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.
12-11-2015 10:49 PM
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?
12-11-2015 11:23 PM
Can you try to use the global DNS (18.104.22.168 or 22.214.171.124)server 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
Please remember to select a correct answer and rate helpful posts
12-11-2015 11:34 PM
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 domain-name company.com enable password encrypted passwd encrypted names ! 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 192.168.100.1 255.255.255.0 ! interface Vlan2 nameif outside security-level 0 ip address x.x.x.x 255.255.255.248 ! ftp mode passive dns server-group DefaultDNS domain-name company.com 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 0.0.0.0 0.0.0.0 static (inside,outside) x.x.x.147 192.168.100.4 netmask 255.255.255.255 static (inside,outside) x.x.x.149 192.168.100.7 netmask 255.255.255.255 static (inside,outside) x.x.x.150 192.168.100.10 netmask 255.255.255.255 access-group acl_out in interface outside route outside 0.0.0.0 0.0.0.0 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 192.168.100.0 255.255.255.0 inside ssh x.x.x.x 255.255.255.255 outside ssh x.x.x.x 255.255.255.255 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 parameters 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
12-11-2015 11:46 PM
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.
Please remember to select a correct answer and rate helpful posts
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: