10-22-2020 10:06 AM
Traffic was flowing through this tunnel but recently stopped. When doing a packet-trace on the outside interface using a valid IP from our customer, the following results, and I can't figure out why Phase: 6 denies the flow. Any thoughts? This tunnel is up, and I see bidirectional traffic on phase 2. Thank you.
packet-tracer input outside tcp ##.138.220.70 2000 #.223.248.13 21 det
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static obj-172.16.11.10 obj-#.223.248.13 destination static CUSTOMER-VPN CUSTOMER-VPN
Additional Information:
NAT divert to egress interface inside
Untranslate #.223.248.13/21 to 172.16.11.10/21
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDE in interface outside
access-list OUTSIDE extended permit ip object-group CUSTOMER-VPN host 172.16.11.10
access-list OUTSIDE remark Permit restricted ICMP traffic
object-group network CUSTOMER-VPN
network-object 192.168.2.0 255.255.255.0
...
network-object host 192.168.107.24
Additional Information:
Forward Flow based lookup yields rule:
in id=0x78394aa8, priority=13, domain=permit, deny=false
hits=3, user_data=0x70f79d00, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=##.138.220.70, mask=255.255.255.255, port=0, tag=0
dst ip/id=172.16.11.10, mask=255.255.255.255, port=0, tag=0, dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static obj-172.16.11.10 obj-#.223.248.13 destination static CUSTOMER-VPN CUSTOMER-VPN
Additional Information:
Static translate ##.138.220.70/2000 to ##.138.220.70/2000
Forward Flow based lookup yields rule:
in id=0x774a6fb8, priority=6, domain=nat, deny=false
hits=65, user_data=0x75c87438, cs_id=0x0, flags=0x0, protocol=0
src ip/id=##.138.220.70, mask=255.255.255.255, port=0, tag=0
dst ip/id=#.223.248.13, mask=255.255.255.255, port=0, tag=0, dscp=0x0
input_ifc=outside, output_ifc=inside
Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x757732a8, priority=1, domain=nat-per-session, deny=true
hits=5344794649, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=any, output_ifc=any
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7582a7d0, priority=0, domain=inspect-ip-options, deny=true
hits=4256517931, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 6
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DROP
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x79902f80, priority=70, domain=ipsec-tunnel-flow, deny=false
hits=699, user_data=0x27e77104, cs_id=0x7da6de88, reverse, flags=0x0, protocol=0
src ip/id=##.138.220.70, mask=255.255.255.255, port=0, tag=0
dst ip/id=#.223.248.0, mask=255.255.255.128, port=0, tag=0, dscp=0x0
input_ifc=outside, output_ifc=any
Result:
input-interface: OUTSIDE
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
ASA5520-A(config)#
10-22-2020 11:16 AM
Inside have by default permit any any
but if you config any ACL on inside interface then this ACL will end with deny any any
so please change the ACL with add permit traffic through the tunnel.
10-22-2020 11:53 AM
Thanks for the response, but there is an ACL on the inside, which ends with "permit ip any any." I figured out the source of the problem, but I'm not sure why the configuration is incorrect. I did a packet-trace (packet-tracer input outside tcp ##.138.220.70 2000 172.16.11.10 21 det) where I accidentally changed the destination from the public address to the private address, and the packet-trace finished successfully . I need to figure out why NATing isn't working.
10-22-2020 11:57 AM
I might add that when I do the packet-trace from the inside to the remote end of the VPN tunnel, there is a phase where 172.16.11.10 is translater to #.223.248.13.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide