Cisco ASA 5510: Cannot Reach Public IP's from Inside Network?

[ken.pleva]

Hello,

I am aware that you cannot ping or contact the outside interface ip address from a host on the inside network. However, my questions is, does this include other public IP addresses as well?

We have 5 public IPs, with an assortment of servers and services running on them, however, I am not able to ping or traceroute to any of their public IP addresses from the inside network that these public addresses represent.

So for example,

If my outside interface ip is 10.1.1.1.

My e-mail server is 10.1.1.2.

My inside network is on 192.168.0.0/24.

NAT and internet access is in general is working and my e-mail server can be contacted using NAT translation and ACL rules from hosts external from my network by using the public addresses. However, my hosts on my internal network are unable to reach my server's public IP address.

One would expect that if a host on my inside network 192.168.0.0 tried to contact a public IP that belong to the e-mail server, the packet would leave out network (using default routes) and go out to the internet and then be re-routed back and reach the firewall again, only to be translated to the e-mail server.

However, I am not able to do this, so, is this by design or have I missed something in my NAT configuration? I have a feeling this is by design since technically the public IPs are being handled by the same ASA device but could anyone verify? I am not finding much luck online.

Thanks!

[John Forester]

Hi Ken,

Do you see where the pings are going?

Does port capture show the pings going out and coming back on the inside and outside interfaces?

Does packet tracer show it going through from both directions? I would perform a packet tracer from outside to the NAT IP that connects to your 192.168 network, and another from inside to your email server to see if both are allowed. If they are, then it could be something other than the firewall. If they are not, then the tracer should tell you where the problem is (usually with me it's an ACL or NAT)

[Andre Neethling]

Ping and traceroute use ICMP. ICMP traffic, by default is not inspected by the ASA. Therefore the reply from the outside host will be dropped at the firewall outside interface. If you add ICMP inspection the ping might work.

[ken.pleva]

ICMP is being inspected by my ASA and pings are working for hosts beyond the outside interface trying to connect to public IP's. This would be an indication that ICMP is being handled properly by my firewall.

[Jouni Forss · Accepted solution]

Hi,

You are only able to connect to a NAT IP address from behind an interface towards which the NAT is performed. This is typically the "outside" interface so only users behind the "outside" interface can access the NAT IP address. Other users will have to use the local IP address by default.

When the NATed host has a public DNS information which the hosts use to connect to the server then there is a possibility that using a "dns" parameter in the Static NAT configuration you can make the ASA modify the DNS reply that the user received that will point to the local IP address. This will allow even the internal users to connect to the NATed host with the DNS name but will actually be connecting to it with the local IP address.

If you wanted to connect to the servers with the public NAT IP address you would essentially have to configure NAT towards the users interface also. The most common situation here is that the servers and users are behind the same ASA interface. In that case it would mean that you would have to

• Configure a Static NAT for the server from "inside" to "inside". You would essentially configure local to public Static NAT between the same interfaces.
• You would also have to configure Dynamic PAT from "inside" to "inside". This is mandatory because otherwise the TCP traffic flow would be wrong and the ASA would drop the connections.

The above solution is not really ideal and in those situation I would typically suggest moving all published servers on their own DMZs which would make the setup a lot clearer. Naturally the best situation is if you are able to allocate a public subnet directly to your LAN for the server use.

If in this case we need to rely on the NAT solution on the "inside" interface then we need to know more about the current configuration and software level used to be able to help.

- Jouni

[ken.pleva]

This is exactly what I was looking for.

It seems counter intuitive to have to NAT inside to inside when you can just have the hosts on the inside network just simply reference the internal addresses. Or do the dns parameter like you suggested.