After a lengthy phone call with Cisco TAC I learned an interesting link between a few commands on an ASA for analyzing tunnels.
Suppose we are REALLY having trouble getting a tunnel up. You are sure the traffic is hitting the firewall that should be encrypted but the tunnel is just not even attempting phase one. These show commands may help identify a problem.
Suppose our tunnel allows traffic from the 10.100.0.0/16 inside subnet to the 10.10.15.0/24 remote subnet.
ASA# PACKET-TRACER INPUT INSIDE ICMP 10.100.10.100 8 0 10.10.15.15. DETAILED
...
Phase: 12
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0xd9354580, priority=70, domain=encrypt, deny=false
hits=2198, user\_data=0x922fac, cs_id=0xd8c45e10, reverse, flags=0x0, protocol=0
src ip=10.100.0.0, mask=255.255.0.0, port=0
dst ip=10.10.15.0, mask=255.255.255.0, port=0, dscp=0x0
Take note of the “user_data” value above. Grab that, and capitalize the hex letters to use this command:
ASA# SHOW ASP TABLE VPN-CONTEXT DETAIL | begin 922FAC
VPN CTX = 0x00922FAC
Peer IP = 10.10.15.0
Pointer = 0xD91404E8
State = UP
Flags = ENCR+ESP
SA = 0x1664DD33
SPI = 0xE5C56C30
Group = 47
Pkts = 362631
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 44
Rekey Call = 44
VPN Filter = <none>
Above is the Context, SA and SPI of the tunnel we are dealing with. You can see the flags above are ENCR which means this is the encaps or outbound packets. Also verify that there are “Pkts” increasing.
You can then verify that SPI is the same that is used in the IPSEC SA (if you have one up) by using this command:
ASA# SHOW CRYPTO IPSEC SA PEER 66.162.66.162
access-list ACL-PPP-VPN extended permit ip 10.100.0.0 255.255.0.0 10.10.15.0 255.255.255.0
local ident (addr/mask/prot/port): (10.100.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.10.15.0/255.255.255.0/0/0)
current\_peer: 66.162.66.162
#pkts encaps: 402798, #pkts encrypt: 403786, #pkts digest: 403786
#pkts decaps: 306215, #pkts decrypt: 306215, #pkts verify: 306215
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 402798, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 988, #pre-frag failures: 0, #fragments created: 1976
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 2693
#send errors: 0, #recv errors: 0
local crypto endpt.: 202.2.202.2, remote crypto endpt.: 66.162.66.162
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: E5C56C30
current inbound spi : A40D0530
inbound esp sas:
spi: 0xA40D0530 (2752316720)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn\_id: 180224, crypto-map: mymap
sa timing: remaining key lifetime (kB/sec): (4372199/2855)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0xE5C56C30 (3854920752)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 180224, crypto-map: mymap
sa timing: remaining key lifetime (kB/sec): (4299344/2855)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
So that’s just another tool that can be used at troubleshooting a VPN tunnel on an ASA. There are a lot of opportunities to learn here. If your packet tracer doesn’t pick up on any encryption then you’ve got a problem probably with the VPN ACL or enabing IPSec on a particular interface. If your asp table isn’t forming an SPI or isn’t getting Pkts then you’ve got a problem to examine probably with IPSec portion of the tunnel. If your IPSEC SA has a different SPI than your asp table then you’ve got a problem to examine that is probably related to mismatched VPN ACLs or NAT’ing incorrectly between the two devices.
Comments