Phase: 6 Type: NAT Subtype: Result: DROP Config: nat (inside) 1 0.0.0.0 0.0.0.0 match ip inside any outside any dynamic translation to pool 1 (22.214.171.124 [Interface PAT]) translate_hits = 20238713, untranslate_hits = 1724138 Additional Information:
Result: input-interface: inside input-status: up input-line-status: up output-interface: outside output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule
Tracing route to google-public-dns-a.google.com [126.96.36.199] over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 10.6.150.1 2 82 ms 79 ms 83 ms wsip-155-155-155-17.oc.oc.net [188.8.131.52] 3 135 ms 133 ms 138 ms wsip-155-155-132-249.oc.oc..net [184.108.40.206]
4 116 ms 175 ms 31 ms 220.127.116.11 5 194 ms 148 ms 152 ms ip155-4-11-10.oc.oc.net [18.104.22.168] 6 215 ms 212 ms 199 ms dllsbbrj02-ge020.rd.dl.oc.net [22.214.171.124] 7 202 ms 26 ms 50 ms langbbrj01-ge050000804.r2.la.oc.net [155.105.30. 181] 8 3 ms 3 ms 4 ms 126.96.36.199 9 239 ms 251 ms 239 ms 188.8.131.52 10 74 ms 40 ms 41 ms 184.108.40.206 11 50 ms 44 ms 68 ms 220.127.116.11 12 * * * Request timed out. 13 36 ms 55 ms 35 ms google-public-dns-a.google.com [18.104.22.168]
10.6.150.1 is a vlan IP for the switch that handles internal routing. It is handing all external traffic off to the ASA. 22.214.171.124 is the gateway on the other side of the ASA. I am not sure why the tracert is ommiting the inside addres of the ASA but there is no other way to get out. The access-list inside_acl extended permit icmp any any is a entry in the ACL on line 2. The blocked host entry is Line 1.
Doing further testing on this to answer your question I determined that my original question is a bit of a red herring.
My initial problem was trying to resolve a issue with a policy map. Troubleshooting that problem I found that the Access list for the policy was never getting hit. So I reasoned that it was a ACL issue. As a test I set a ping 126.96.36.199 -t on a client in the affected subnet. Then I added 188.8.131.52 to a blocked host rule. When the ping traffic continued I reasoned it was a subnet/ACL issue I described.
Silly me. Because the connection was established prior to adding the deny rule it was not interrupted. Once I stopped the persistent ping, and restarted it, the traffic was properly blocked.
I am left with my original issue, and none the wiser to the source of my problem.
I am trying to set a rate limit on vlan03. The rate limit for colo works as expected. The vlan03 access list is never hit, so I am assuming that is why the policy is not kicking in.
access-list rate_limit_colo_acl extended permit ip host 184.108.40.206 any access-list rate_limit_colo_acl extended permit ip any host 220.127.116.11 access-list rate_limit_vlan03_acl extended permit ip 10.6.150.0 255.255.255.0 any access-list rate_limit_vlan03_acl extended permit ip any 10.6.150.0 255.255.255.0 ! class-map rate_limit_colo_map match access-list rate_limit_colo_acl class-map rate_vlan03_map match access-list rate_limit_vlan03_acl class-map inspection_default match default-inspection-traffic ! ! policy-map type inspect dns preset_dns_map parameters 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 sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp policy-map policy_rate_limit_map class rate_limit_colo_map police output 1000000 5000 police input 1000000 5000 class rate_vlan03_map police output 10000 3000 police input 10000 3000 ! service-policy global_policy global service-policy policy_rate_limit_map interface outside
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...