cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1805
Views
5
Helpful
3
Replies

Problem with traffic through IPSec site-to-site tunnel

ABaker94985
Spotlight
Spotlight

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)#

3 Replies 3

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. 

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. 

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. 

Review Cisco Networking for a $25 gift card