cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4742
Views
0
Helpful
3
Replies

packet-tracer vs. site-to-site tunnel from outside

lcaruso
Level 6
Level 6

Hi,

Packet tracer works great verifying my site-to-site ipsec tunnel from inside, but when I run it from outside and give it an ip address that would have been classified as interesting on the peer device, it fails.

This would not be return traffic, but initiating traffic from the peer site.

I'm assuming this is because packet tracer has no way of simulating a packet arriving on the outside interface is already in the tunnel and enrcypted, as the trace did not show any vpn stages.

Packets arriving from the lab setup across the tunnel are allowed, just not the packet tracer.

Appreciate any input. Don't always have the benefit of a lab setup to verify.

1 Accepted Solution

Accepted Solutions

jubetz
Level 1
Level 1

Your only option there is to capture the encrypted packets in a capture with the "trace" option.  Then you can do "show capture packet-number <#> trace" to feed that packet through packet-tracer and it will make it past the vpn-decrypt section.

Still not very helpful unless you don't have much traffic over the VPN.  There's no way to know if the encapsulated traffic is what you were hoping to get.

HTH,

-jb

View solution in original post

3 Replies 3

your situation is normal. I tried the same packet tracer using our site to site VPN and I get the same result.

This is what I get:

ASA-1(config)# packet-tracer input outside icmp 192.168.70.10 8 0 172.16.12$

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   172.16.128.0    255.255.240.0   inside

Phase: 3

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xc6464cc8, priority=0, domain=permit, deny=true

hits=22753, user_data=0x9, cs_id=0x0, flags=0x1000, protocol=0

src ip=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

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

The interface ACL is the one dropping it. It seems that the sysopt connection permit-vpn doesn't work with the packet tracer

jubetz
Level 1
Level 1

Your only option there is to capture the encrypted packets in a capture with the "trace" option.  Then you can do "show capture packet-number <#> trace" to feed that packet through packet-tracer and it will make it past the vpn-decrypt section.

Still not very helpful unless you don't have much traffic over the VPN.  There's no way to know if the encapsulated traffic is what you were hoping to get.

HTH,

-jb

that's a nifty idea--didn't know about that--thanks!

Review Cisco Networking for a $25 gift card