Solved: Re: ASA NAT/Traceroute Inside to Outside Issues

hiltonstroud · ‎05-21-2013

Hi All,

Product in question: ASA5512-x in HA Active/Standby Failover mode

When running a ping from the inside network to a device on the internet I recieve replies and all is good. However when running a traceroute from inside the network to a device on the internet I receive timeouts which look to be caused by a ACL deny rule, that being "outside/internet_access_in" If I quickly add an access rule for "outside/internet" incoming rule and allow any any with ICMP_Group then I get replies and the ACL is allowing it, however the replies for the traceroute are always the same, which is the device IP your tracing. I wouldn't think you would want an outside/internet incoming rule for this kind of service as it would open you up and kinda defeat the purpose of firewal etc.

To me it sounds like NAT is certainly causing some weirdness here, possilby they way it's setup...

The following is the explanation from the Deny message on syslog.

%ASA-4-106023: Deny protocol src 
[interface_name:source_address/source_port] [([idfw_user|FQDN_string], sg_info)] 
dst interface_name:dest_address/dest_port [([idfw_user|FQDN_string], sg_info)] 
[type {string}, code {code}] by access_group acl_ID [0x8ed66b60, 0xf8852875]

A real IP packet was denied by the ACL. This message appears even if you do not have the log option enabled for an ACL. The IP address is the real IP address instead of the values that display through NAT. Both user identity information and FQDN information is provided for the IP addresses if a matched one is found. The ASA logs either identity information (domain\user) or FQDN (if the username is not available). If the identity information or FQDN is available, the ASA logs this information for both the source and destination.

Following are the 2 NAT rules in place at the moment - The first one was auto created when configuration a site-to-site VPN which is meant to tell the traffice over the VPN not to NAT.

nat (inside,internet) source static Private_Network_Classes Private_Network_Classes destination static Test_VPN_Site Test_VPN_Site no-proxy-arp route-lookup

nat (inside,internet) source dynamic any interface

I hope this gives some insight into the issue I am having and someone can suggest some fixes/reconfig's to work around this. It certainly hasn't been easy trying to explain what is occuring here in writting.

Thank you for your time.

Jouni Forss · ‎05-26-2013

Hi,

To my understanding by default the

inspect icmp

inspect icmp error

Should handle most of what you need related to ICMP. I think you need "inspect icmp error" to make it possible for the devices in between your source host and the destination host to be able to reply through the ASA. If not you should look at opening the below mentioned ICMP messages.

I would say its rather common to allow certain ICMP messages through the firewall. You dont have to allow ICMP echo but rather ICMP messages that are replys from remote devices.

I guess the most usual are

time-exceeded

unreachable

echo-reply

You could open the above and not allow any other ICMP messages.

With regards to the interface ICMP. This is not controlled by the default interface ACL. This is controlled by the command "icmp". By default each interface answers to ICMP from anywhere.

So you would have to use for example

icmp deny any outside

To block ICMP. But to my understanding this will also result in the fact that the ASA cant ping anything through its "outside" unless you add "permit" format command before the "deny" that permit "echo-reply" and the other types I mentioned earlier.

icmp permit any echo-reply outside

icmp permit any time-exceeded outside

icmp permit any unreachable outside

icmp deny any outside

I dont know why the default setting is so. Might be because the ASA is shipped without any interface configurations other than the management interface. So there is no way to set the interface ICMP configuration when no such interface exists as "outside".

Hope this helps

Remember to mark the reply as the correct answer if it answered your question. And/or rate helpfull answer.

Naturally ask more if needed

- Jouni

View solution in original post

Jouni Forss · ‎05-22-2013

Hi,

Have you enabled ICMP Inspection?

For example

fixup protocol icmp

fixup protocol icmp error

Or you add them under the "policy-map" configurations along with the other "inspect"

inspect icmp

inspect icmp error

I remember reading on these forums that this might be some bug.

- Jouni

hiltonstroud · ‎05-22-2013

Hi Jouni,

Yes I beleive ICMP Inspecition is enabled, for both ICMP and ICMP error, I see this in the ASDM and on CLI, see below

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

inspect icmp

inspect icmp error

-----------------------------------------------------------------------------------------------------------------------

I have not run the "fixup protocol icmp" - I am not sure what this is?

EIDT: After a quick look into this fixup protocol I see it's the same as enabling the inspect icmp & icmp error as shown above, well from what I understand, please correct me if I am wrong.

Jouni Forss · ‎05-23-2013

Hi,

To my understanding there shouldnt be many things preventing traceroute through the firewall.

Usually its related to the Inspections and/or lacking the ACL statements on the "outside" interface which allow echo-reply, time-exceeded and unreachable messages.

Could you post some exact Syslog messages when a ICMP message is blocked? (Can naturally mask the public IP addresses) To my understanding the ASA is at the moment blocking the messages that the routers in between the destination and the source are sending to the source host behind the ASA.

One other usual problem regarding ASA and traceroute is also the fact that the ASA doesnt show up on the traceroute. IF that is required you will also need some additional configurations.

There is also the possibility that you are running into some software bug. To try to determine that we would need to know your current software level.

And regarding the "fixup" commands. These are the predecessor of "inspect" on old Cisco PIX firewalls. The ASAs still seem to support these old commands but ASA will convert the commands to "inspect" configurations. Sometimes its just faster and easier to use the "fixup" command to insert the configuration than going under the "policy-map" configurations.

- Jouni

Julio Carvajal · ‎05-23-2013

Hello,

Have to agree with Jouni,

When we see this issues the command that fix it is the "fixup protocol icmp error" but it seems that it's doing nothing here,

So I would say captures on the inside and outside plus logs would allow a better troubleshooting here,

Can you share the show service-policy ( did you perform a clear local-host after entering the fixup protocol icmp and icmp error?

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

hiltonstroud · ‎05-26-2013

Hi Jcarvaja,

I have not perfomed a "clear local-host" after entering the fixup protocol commands. May I ask what this command is and what it may do to fix the issue, I would like to understand it.

As requested below is output from "show service-policy"

Global policy:

Service-policy: global_policy

Class-map: inspection_default

Inspect: dns preset_dns_map, packet 662143, lock fail 0, drop 14018, reset-drop 0, v6-fail-close 0

Inspect: ftp, packet 17758, lock fail 0, drop 0, reset-drop 0, v6-fail-close 0

Inspect: h323 h225 _default_h323_map, packet 0, lock fail 0, drop 0, reset-drop 0, v6-fail-close 0