ASA bug breaking traceroute functionality? 7.2(5)

I am running an ASA 7.2(5)/ASDM 5.2(5), this is the ASA at my house.  And I am not sure when it started, but I cannot get traceroutes to work from my mac to the Internet.  I can traceroute on my LAN, but not going through the ASA, I just get * * *.  Here are the related parts of my ASA config:

same-security-traffic permit intra-interface
access-list outsideIn extended permit icmp any any traceroute 
access-list outsideIn extended permit icmp any any echo 
access-list outsideIn extended permit icmp any any echo-reply 
access-list outsideIn extended permit icmp any any source-quench 
access-list outsideIn extended permit icmp any any unreachable 
access-list outsideIn extended permit icmp any any time-exceeded 
access-group outsideIn in interface outside

global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,outside) interface 172.16.5.30 netmask 255.255.255.255 dns 

policy-map global_policy
 class inspection_default
  inspect icmp 
  inspect icmp error 
!
service-policy global_policy global
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
A few notes about the above:
My Computer: 172.16.5.229
My ASA Outside: 174.61.8.28
Synology DS1010+: 172.16.5.30
So I have found a bit about why this wasn’t working, and interested to get some opinions from the ASA gurus on here:

The ASA is sending the time-exceeded’s to 172.16.5.30, which is my Synology:

08 packets captured
   1: 01:52:42.269090 802.1Q vlan#1 P0 172.16.5.229 > 8.8.8.8: icmp: echo request 
   2: 01:52:42.309355 802.1Q vlan#1 P0 64.233.174.2 > 172.16.5.30: icmp: time exceeded in-transit 
   3: 01:52:47.268159 802.1Q vlan#1 P0 172.16.5.229 > 8.8.8.8: icmp: echo request 
   4: 01:52:47.311141 802.1Q vlan#1 P0 66.249.94.22 > 172.16.5.30: icmp: time exceeded in-transit 
   5: 01:52:52.268906 802.1Q vlan#1 P0 172.16.5.229 > 8.8.8.8: icmp: echo request 
   6: 01:52:52.313368 802.1Q vlan#1 P0 66.249.94.22 > 172.16.5.30: icmp: time exceeded in-transit 
My ASA is very basic, I just PAT everything out the outside interface.  however I do have one static:
static (inside,outside) interface 172.16.5.30 netmask 255.255.255.255 dns 
So my thought with this, is anything coming into the ASA, that does not belong to some other xlate would goto 172.16.5.30.  there are maybe a handfull of ports I send its way via the outside ACL:
access-list outsideIn extended permit tcp any interface outside eq www 
access-list outsideIn extended permit tcp any interface outside eq 5001 
access-list outsideIn extended permit tcp any interface outside eq 5432 
access-list outsideIn extended permit udp any interface outside eq 5432 
access-list outsideIn extended permit tcp any interface outside eq 6881 
access-list outsideIn extended permit tcp any interface outside eq 9997 
access-list outsideIn extended permit tcp any interface outside eq 9998 
access-list outsideIn extended permit tcp any interface outside eq 9999 
access-list outsideIn extended permit tcp any interface outside eq ftp-data 
access-list outsideIn extended permit tcp any interface outside eq ftp 
access-list outsideIn extended permit tcp any interface outside eq 5006 
access-list outsideIn extended permit tcp any interface outside eq 7001 
access-list outsideIn extended permit tcp any interface outside eq 6900 
But it should not take a time-exceeded packet and send it to 172.16.5.30.  The ASA should be smart enough to know that it was in response to a UDP packet sent from 172.16.5.229 (my laptop).  It seems like it could be a bug.  I only have 1 IP address, it’s dynamically assigned, so I static my Synology to it and I also NAT everything else to it:
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
I am pretty sure this is allowed.  The only other way I could do it would be to make a ton of “statics” that were port based, one for each of the ports in the ACL……….just would be more administrative work, but I wonder if one way or the other is truly correct.  You can see the xlate is clearly there:
home-asa# show xlate | inc ICMP
4 in use, 234 most used
Global 174.61.8.28 Local 172.16.5.30
PAT Global 174.61.8.28(28476) Local 172.16.5.229 ICMP id 41382 
As a test, I got rid of my single “catch all” static and replaced it with static PAT’s:
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,outside) tcp interface www 172.16.5.30 www netmask 255.255.255.255  dns 
static (inside,outside) tcp interface 5001 172.16.5.30 5001 netmask 255.255.255.255  dns 
static (inside,outside) tcp interface 5432 172.16.5.30 5432 netmask 255.255.255.255  dns 
static (inside,outside) udp interface 5432 172.16.5.30 5432 netmask 255.255.255.255  dns 
static (inside,outside) tcp interface 6881 172.16.5.30 6881 netmask 255.255.255.255  dns 
static (inside,outside) tcp interface 9997 172.16.5.30 9997 netmask 255.255.255.255  dns 
static (inside,outside) tcp interface 9998 172.16.5.30 9998 netmask 255.255.255.255  dns 
static (inside,outside) tcp interface 9999 172.16.5.30 9999 netmask 255.255.255.255  dns 
static (inside,outside) tcp interface ftp-data 172.16.5.30 ftp-data netmask 255.255.255.255  dns 
static (inside,outside) tcp interface ftp 172.16.5.30 ftp netmask 255.255.255.255  dns 
static (inside,outside) tcp interface 5006 172.16.5.30 5006 netmask 255.255.255.255  dns 
static (inside,outside) tcp interface 7001 172.16.5.30 7001 netmask 255.255.255.255  dns 
static (inside,outside) tcp interface 6900 172.16.5.30 6900 netmask 255.255.255.255  dns 
This “fixed” the issue.  But now I remember why I did the single static.  DNS Doctoring doesn’t work with static PAT, despite that it allows you to configure the “dns” keyword.  The only way to actually have it work is with a static NAT.  So I guess I am going to just lose the ability to have traceroute (and god know what else) working, in exchange for working DNS Doctoring.  I never noticed anything wasn’t working until now anyways.
Still, I call it a bug, because my laptop should create a XLATE, that the ASA can tie to the time-exceeded coming back…….I don’t know, it just doesn’t seem like the normal way an ASA would work.  At least now its working, I will just have to add a static entry every time I open a port to match my ACL.
Here you can see the Wireshark capture of an ICMP packet going from 8.8.8.8 to the outside of the ASA:
 You can see that under the ICMP section of the packet, there is a IPv4 section, that shows the packet came from the ASA (was NAT’ed) and the destination was 8.8.8.8.  This capture was made on the “outside” interface of the ASA.
Similarly, you can see below is a Wireshark capture of the same packet, captured on the “inside” interface of the ASA:
In this capture you can see that the IPv4 header shows a destination of 172.16.5.30, which is my Synology which has the “catch all” static NAT.  This is incorrect, this is in response to a traceroute ran on my Mac, which his 172.16.5.229.  You can see in the ICMP header, there is a IPv4 subsection that shows correctly that the original source of the packet was my Mac 172.16.5.229.  So the ASA obviously had the information maintained in it’s state tables, but did not correctly fixup and route this packet.
If anyone know’s if this is a configuration problem or indeed a bug please let me know.  With only a single IP address to share at my house, and the need for so many ports to goto my Synology, and the need for DNS Doctoring, I figured what I was originally doing was quite fine, and in fact everything that I could tell seemed to be working except traceroute.
This entry was posted in Cisco and tagged . Bookmark the permalink.

Leave a Reply