ASA L2L IPsec not encrypting the traffic (Duplicate SPI troubleshooting)
What is an SPI ?
SPIs are the components that are going to be used to provide
protection to an outgoing packet ( Security Parameter Index ), so we are
going to see that it will identify a packet that is going to be
protected via an encryption
How to identify that we have duplicate SPIs: ?
1) Do a packet-tracer for the traffic that is supposed to go over the
VPN tunnel and get encrypted , include the Detail keyword to get the
information need it to proceed. and look at VPN - Allow section.
packet-tracer input inside udp 10.255.203.102 1610 10.220.100.17 3389 DETAIL
Phase: 9
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0xcf20d730, priority=70, domain=encrypt, deny=false
hits=3016, *user_data=0x2d2ea0a4*, cs_id=0xcd3b96f0, reverse, flags=0×0,
protocol=0
src ip=10.255.203.0, mask=255.255.255.0, port=0
dst ip=10.220.100.0, mask=255.255.255.0, port=0, dscp=0×0
The value highlighted is the Virtual-Context being used for that VPN
traffic (There are several VPN contexts used by a single crypto-map.)
2) Copy the user_data vlaue from the above output and then paste it a notepad and capitalize the letters and then we are going to do a show asp table vpn-context search (We must capitalize the letters) .
show asp table vpn-context detail | begin *0x2D2EA0A4*
VPN CTX =* 0x2D2EA0A4*
Peer IP = 10.220.100.0
Pointer = 0xD26F7CA8
State = UP
Flags = *ENCR+ESP*
SA =* 0x6B856011*
SPI =* 0x25A3076D*
Group = 7
Pkts = *41006*
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 9
Rekey Call = 9
Okay now we have the *VPN context , SA and SPI* being used for that
particular VPN traffic (remember that multiple VPN context can be used
for*different subnets*, this is why one subnet traffic across the VPN
might work and other ones not on the same Crypto-Map).
We can also see that it says*ENCR+ESP* which means that it’s encrypting
the traffic. We also see that it has a value of 4006 (Packets being
encrypted) So for the sake of the Packet-tracer everything is good.
3) Now let’s go to the Show crypto IPSec SA to get the SPI (in a perfect
world it should be the same one than the one used for the packet
tracer *0x25A3076D) *But let’s see if there is an issue:
sh crypto ipsec sa peer X.X.X.X ( We will focus only on the current
outbound esp SPI as the problem is with encryption traffic)
peer address: X.X.X.X
Crypto map tag: TEST, seq num: 40, local addr: Y.Y.Y.Y
access-list TEST permit ip 10.255.203.0 255.255.255.0 10.220.100.0
255.255.255.0
local ident (addr/mask/prot/port): (10.255.203.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.220.100.0/255.255.255.0/0/0)
current_peer: X.X.X.X
* #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0*
* #pkts decaps: 484, #pkts decrypt: 484, #pkts verify: 484*
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: Y.Y.Y.Y, remote crypto endpt.: X.X.X.X
path mtu 1500, ipsec overhead 58, media mtu 1500
* current outbound spi: A19EC57E*
inbound esp sas:
spi: 0xCF559E0D (3478494733)
transform: esp-3des esp-md5-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 43950080, crypto-map: TEST
sa timing: remaining key lifetime (kB/sec): (4373958/27285)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x25A3076D (2711537022)
transform: esp-3des esp-md5-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 43950080, crypto-map: TEST
sa timing: remaining key lifetime (kB/sec): (4374000/27284)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0×00000000 0×00000001
What are the interesting outputs here:
1) No packets are being encrypted, we are just decrypting traffic.
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 484, #pkts decrypt: 484, #pkts verify: 484
2) We have an SPI value for the IPSec SA which is different than the
one used for the Packet-tracer
Packet tracer *25A3076D*
SPI * A19EC57E*
So what is next..
Well now that we have the SPI for the real IPSec traffic (not the
virtual-packet tracer flow) let’s look for the VPN context of that SPI:
sh asp table vpn-context detail | begin *A19EC57E*
* *
*VPN CTX = 0x2D80E6FC*
Peer IP = 10.220.100.0
Pointer = 0xD08A30D0
State = UP
Flags = ENCR+ESP
*SA = 0x6D5DAF29*
*SPI = 0xA19EC57E*
Group = 0
Pkts = 0
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 0
Rekey Call = 0
And there you go, 2 different VPN context and SPIs assigned to the same
traffic flow.. And in this one ( the real one) there are no packets
being encrypted.. which matches what the show crypto IPSec sa shows…
Now that we have recognized the issue, How do we fix it:
Well this is certainly a bug (an unexpected behavior) a reboot will fix
it! I know.. I know.. A reboot is not good enough .
Do this: clear crypto ipsec sa inactive
https://tools.cisco.com/bugsearch/bug/CSCtd36473
SPIs are the components that are going to be used to provide
protection to an outgoing packet ( Security Parameter Index ), so we are
going to see that it will identify a packet that is going to be
protected via an encryption
How to identify that we have duplicate SPIs: ?
1) Do a packet-tracer for the traffic that is supposed to go over the
VPN tunnel and get encrypted , include the Detail keyword to get the
information need it to proceed. and look at VPN - Allow section.
packet-tracer input inside udp 10.255.203.102 1610 10.220.100.17 3389 DETAIL
Phase: 9
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0xcf20d730, priority=70, domain=encrypt, deny=false
hits=3016, *user_data=0x2d2ea0a4*, cs_id=0xcd3b96f0, reverse, flags=0×0,
protocol=0
src ip=10.255.203.0, mask=255.255.255.0, port=0
dst ip=10.220.100.0, mask=255.255.255.0, port=0, dscp=0×0
The value highlighted is the Virtual-Context being used for that VPN
traffic (There are several VPN contexts used by a single crypto-map.)
2) Copy the user_data vlaue from the above output and then paste it a notepad and capitalize the letters and then we are going to do a show asp table vpn-context search (We must capitalize the letters) .
show asp table vpn-context detail | begin *0x2D2EA0A4*
VPN CTX =* 0x2D2EA0A4*
Peer IP = 10.220.100.0
Pointer = 0xD26F7CA8
State = UP
Flags = *ENCR+ESP*
SA =* 0x6B856011*
SPI =* 0x25A3076D*
Group = 7
Pkts = *41006*
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 9
Rekey Call = 9
Okay now we have the *VPN context , SA and SPI* being used for that
particular VPN traffic (remember that multiple VPN context can be used
for*different subnets*, this is why one subnet traffic across the VPN
might work and other ones not on the same Crypto-Map).
We can also see that it says*ENCR+ESP* which means that it’s encrypting
the traffic. We also see that it has a value of 4006 (Packets being
encrypted) So for the sake of the Packet-tracer everything is good.
3) Now let’s go to the Show crypto IPSec SA to get the SPI (in a perfect
world it should be the same one than the one used for the packet
tracer *0x25A3076D) *But let’s see if there is an issue:
sh crypto ipsec sa peer X.X.X.X ( We will focus only on the current
outbound esp SPI as the problem is with encryption traffic)
peer address: X.X.X.X
Crypto map tag: TEST, seq num: 40, local addr: Y.Y.Y.Y
access-list TEST permit ip 10.255.203.0 255.255.255.0 10.220.100.0
255.255.255.0
local ident (addr/mask/prot/port): (10.255.203.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.220.100.0/255.255.255.0/0/0)
current_peer: X.X.X.X
* #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0*
* #pkts decaps: 484, #pkts decrypt: 484, #pkts verify: 484*
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: Y.Y.Y.Y, remote crypto endpt.: X.X.X.X
path mtu 1500, ipsec overhead 58, media mtu 1500
* current outbound spi: A19EC57E*
inbound esp sas:
spi: 0xCF559E0D (3478494733)
transform: esp-3des esp-md5-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 43950080, crypto-map: TEST
sa timing: remaining key lifetime (kB/sec): (4373958/27285)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x25A3076D (2711537022)
transform: esp-3des esp-md5-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 43950080, crypto-map: TEST
sa timing: remaining key lifetime (kB/sec): (4374000/27284)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0×00000000 0×00000001
What are the interesting outputs here:
1) No packets are being encrypted, we are just decrypting traffic.
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 484, #pkts decrypt: 484, #pkts verify: 484
2) We have an SPI value for the IPSec SA which is different than the
one used for the Packet-tracer
Packet tracer *25A3076D*
SPI * A19EC57E*
So what is next..
Well now that we have the SPI for the real IPSec traffic (not the
virtual-packet tracer flow) let’s look for the VPN context of that SPI:
sh asp table vpn-context detail | begin *A19EC57E*
* *
*VPN CTX = 0x2D80E6FC*
Peer IP = 10.220.100.0
Pointer = 0xD08A30D0
State = UP
Flags = ENCR+ESP
*SA = 0x6D5DAF29*
*SPI = 0xA19EC57E*
Group = 0
Pkts = 0
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 0
Rekey Call = 0
And there you go, 2 different VPN context and SPIs assigned to the same
traffic flow.. And in this one ( the real one) there are no packets
being encrypted.. which matches what the show crypto IPSec sa shows…
Now that we have recognized the issue, How do we fix it:
Well this is certainly a bug (an unexpected behavior) a reboot will fix
it! I know.. I know.. A reboot is not good enough .
Do this: clear crypto ipsec sa inactive
https://tools.cisco.com/bugsearch/bug/CSCtd36473
0 comments:
Post a Comment