AnyConnect - how to use packet tracer for VPN traffic?

[Eric Snijders]

Hi All,

So let's say i have a basic AnyConnect configuration on the Outside interface.
Now i'm connected with AnyConnect and got a IP from the ip local pool, let's say: 192.168.100.100.

If i want to do a packet trace on the ASA to verify ACL's and Routes etc, should i enter it like this:
packet-tracer input Outside tcp 192.168.100.100 80 <destination> 80

The reason i'm asking this is because packet-tracer seems to give strange output. If i use a source ip of the VPN pool which has been given out (show vpn-sessiondb anyconnect) i'm getting a result of drop in the following section:

Phase: 10
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DROP
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7fffe2718510, priority=69, domain=ipsec-tunnel-flow, deny=false
hits=57, user_data=0x5780d4, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=192.168.100.100, mask=255.255.255.255, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=Outside, output_ifc=any

The strange thing with this output is that i'm still able to communicate with the destination over the given protocol. So even though the packet-trace results in a DROP, the communication is still possible (which in this case was the purpose so that's alright).

Now, if i do the same packet-trace, but this with with an IP of the local pool which has NOT been given out, i'm getting all ALLOW's.

[Karsten Iwen]

You need ASA version 9.9 to simulate decrypted packets. On earlier releases, you only can simulate native communication:

https://www.cisco.com/c/en/us/td/docs/security/asa/asa99/release/notes/asarn99.html#reference_k44_rd5_p1b

[Eric Snijders]

I am running:

Cisco Adaptive Security Appliance Software Version 9.9(1)2
Firepower Extensible Operating System Version 2.3(1.54)
Device Manager Version 7.9(1)

[Rahul Govindan]

Add the "decrypted" keyword at the end of the command.

I did not know this came out until Karsten pointed out the new release notes :)

ciscoasa# packet-tracer input outside tcp 172.16.50.2 80 172.16.20.1 443 detailed decrypted

*********************************************************************
WARNING: An existing decryption SA was not found. Please confirm the
IPsec Phase 2 SA or Anyconnect Tunnel is established.
*********************************************************************

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2aaac325fbb0, priority=1, domain=permit, deny=false
hits=2151306, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=outside, output_ifc=any

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 172.16.30.2 using egress ifc inside

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static NETWORK_OBJ_172.16.50.0_28 NETWORK_OBJ_172.16.50.0_28 no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface inside
Untranslate 172.16.20.1/443 to 172.16.20.1/443

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: (vpn-context-expired) Expired VPN context

[Igor.Dyakonov]

It's also helpful to use an option bypass-checks

ciscoasa# packet-tracer input outside tcp 172.16.50.2 80 172.16.20.1 443 detailed decrypted  bypass-checks

This option will permit to see all phases in packet-tracer like applied NAT, IP-OPTIONS etc.

[KevinLi2019]

While this is an older thread, it still helped me to understand the packet-tracer tool deeper.

Although the ASA version I am on is 9.8.4, which does not support the "decrypted", I could still use the packet-tracer to troubleshoot the AnyConnect VPN by putting it on the inside interface, with the internal IP in the source address while the VPN client IP in the destination address. This is probably an example of what Karsten Iwen had mentioned as "simulate native communication".

Just wanted to share here, in case it might be helpful for someone else.