View number of IPSEC tunnels?

CiscoPurpleBelt · ‎03-08-2019

From the ASA, if y ou do sh crypto ikev2 sa, it show the following below. Are all the child SA just allowed subnets on the tunnel?

Session-id:2758, Status:UP-ACTIVE, IKE count:1, CHILD count:14

Tunnel-id Local Remote Status Role
1682665127 X.X.X.6/500 X.X.X.0/500 READY RESPONDER
Encr: AES-CBC, keysize: 256, Hash: SHA384, DH Grp:21, Auth sign: PSK, Auth verify: PSK

Life/Active Time: 86400/18416 sec

Child sa: local selector X.X.X..0/0 - 1X.X.X..255/65535
remote selector X.X.X..160/0 - X.X.X.1/65535
ESP spi in/out: 0x6d1f4027/0xbbe517cf
Child sa: local selector X.X.X.28/0 - X.X.X.255/65535
remote selector X.X.X.60/0 - X.X.X.91/65535
ESP spi in/out: 0xbb935ee4/0xa7642a72

Rob Ingram · ‎03-08-2019

Yes. The networks defined in the crypto ACL will be identified as CHILD SA. If you have multiple networks defined in the ACL you will have multiple CHILD SAs. 1 IKE SA (identifying the VPN peers) will be created, then a CHILD SA per network.

You can use the command show vpn-sessiondb detail l2l to indicate total number of IKE/IPSec tunnels

CiscoPurpleBelt · ‎03-08-2019

Awesome!
So this particular example is IKEv2.
So 1IKE SA identifying peers like the "READY RESONDER" above correct?
So what would be best way to determine a CHILDE SA (so basically the remote site) is down or not properly sending traffic?

Rob Ingram · ‎03-08-2019

show crypto ikev2 sa detail will show you the IKE SA and CHILD count

ASA-1# show crypto ikev2 sa detail

IKEv2 SAs:

Session-id:1, Status:UP-ACTIVE, IKE count:1, CHILD count:2

Tunnel-id Local Remote Status Role
2165229 1.1.1.1/500 3.3.3.1/500 READY RESPONDER
Encr: AES-CBC, keysize: 256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 0/544 sec
Session-id: 1
Status Description: Negotiation done
Local spi: 2C539E8C33326D0E Remote spi: 50BCD8D9AFD45EE9
Local id: 1.1.1.1
Remote id: 3.3.3.1
Local req mess id: 41 Remote req mess id: 42
Local next mess id: 41 Remote next mess id: 42
Local req queued: 41 Remote req queued: 42
Local window: 1 Remote window: 1
DPD configured for 10 seconds, retry 2
NAT-T is not detected
IKEv2 Fragmentation Configured MTU: 576 bytes, Overhead: 28 bytes, Effective MTU: 548 bytes
Child sa: local selector 192.168.100.0/0 - 192.168.100.255/65535
remote selector 10.30.0.0/0 - 10.30.3.255/65535

Child sa: local selector 10.10.0.0/0 - 10.10.0.255/65535
remote selector 10.30.0.0/0 - 10.30.3.255/65535

Use the command show crypto ipsec sa and check the encaps|decaps these should be increasing as packets traverse the tunnel. If they are unequal, then you've probably got a nat or routing issue on one end of the tunnel.

ASA-1(config)# show crypto ipsec sa
interface: OUTSIDE
Crypto map tag: CMAP, seq num: 3, local addr: 1.1.1.1

access-list VPN_3 extended permit ip 10.10.0.0 255.255.255.0 10.30.0.0 255.255.252.0
local ident (addr/mask/prot/port): (10.10.0.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.30.0.0/255.255.252.0/0/0)
current_peer: 3.3.3.1

#pkts encaps: 103, #pkts encrypt: 103, #pkts digest: 103
#pkts decaps: 103, #pkts decrypt: 103, #pkts verify: 103

HTH

CiscoPurpleBelt · ‎03-09-2019

Awesome thanks! I am a bit confused about couple things. So for my particular setup, We have these tunnels built as shown in my post, they go through another transport provider who handles the connections to our remote site. Are those child SAs the tunnel subnets for the natted ip addresses of the remote sites? Wouldn't the remote end device be at the actual remote site? Let me know if I am not explaining things clearly in what I am trying to ask. Thanks!

Rob Ingram · ‎03-09-2019

Hi,
Not entirely sure I am following...but whatever IP address/networks your devices are communicating with needs to be defined in the crypto ACL, which would create the associated CHILD SA. If the remote networks are natted then you'd need to define that in your crypto ACL.

HTH

CiscoPurpleBelt · ‎03-09-2019

I attached a pic to help - don't have Visio. I also made another post as I know this getting a bit more in depth. Basically need understanding.

Let's say HQ router is head end router with all IPSEC configs for remote sites.

The circuit goes to another location (Provider in diagram) who handles the physical connections to the remote sites.

So remote end configs for the tunnels are still built on devices at the remote site router or ASA, etc. correct?

Would these tunnels for the remote sites be the child SAs? I am confused where or what would the main SA or tunnel be?

So does the Transport provider just need our public ip addresses since they are not supposed to know about the tunnels?

Rob Ingram · ‎03-09-2019

The provider would just need to be able to route to between the public/external IP addresses of your router or ASA at all of the sites. They wouldn't know about the networks being tunnel through the VPN, as they'd just see a load of encrypted traffic between the public/external IP addresses of your router/ASA.

HTH

CiscoPurpleBelt · ‎03-10-2019

Great info!
So below I see one main tunnel I guess then a bunch of child SAs underneath (just as it shows in the GUI/ASDM). To my understanding, all the child SAs are different remote sites that go through the transport provider. I am basically trying to interpret the below because to my understanding, we have VPN tunnels that go through one transport location that handles the connections to the remote sites. Is my main tunnel is the "1682665127 X.X.X.6/500 X.X.X.0/500 READY RESPONDER". Does this sound about right? How is this configured?

CiscoPurpleBelt · ‎03-11-2019

So can the different networks composing of the child SAs see each other's traffic since they do ride the same tunnel or is it basically like separate tunnels within the client/peer tunnel?