GETVPN "show crypto ipsec sa" output question

[whistleblower14]

Hi,

I´m dealing with GETVPN and I´ve a question regarding the output of "show crypto ipsec sa"...

the ACL on the KS is configured the following way:

permit ip 172.16.0.0 0.3.255.255 192.168.0.0 0.0.255.255
permit ip 192.168.0.0 0.0.255.255 172.16.0.0 0.3.255.255

why does the crypto ipsec output on the GM show´s the encrypted- and decrypted packets in different sections/lines?

local ident (addr/mask/prot/port): (172.16.0.0/255.252.0.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 271179882, #pkts decrypt: 271179882, #pkts verify: 271179882

local ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (172.16.0.0/255.252.0.0/0/0)
#pkts encaps: 255682246, #pkts encrypt: 255682246, #pkts digest: 255682246
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

[MHM Cisco World]

can I see the config of KS and GM ?

[Rob Ingram]

@whistleblower14 in the counters, when you see decaps but no encaps, that is usually a NAT or routing issue.

Can you provide this information to review please?

[whistleblower14]

@Rob Ingram what information will you need exactly? Unfortunately I have no access to login into the KS...
For me it looks like it´s working but I don´t understand why the output is presented that way

[Rob Ingram]

@whistleblower14 take this output...

local ident (addr/mask/prot/port): (172.16.0.0/255.252.0.0/0/0)
remote ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 271179882, #pkts decrypt: 271179882, #pkts verify: 271179882

Traffic is not being sent (encrypted) from 172.16.0.0 to 192.168.0.0
...but traffic is being received (decrypted) from 192.168.0.0 to 172.16.0.0

So does the network 172.16.0.0 know to route to 192.168.0.0 via the GETVPN router? That might explain why there is no encaps. Do a traceroute.

And the reason there is nothing received (decrypted) in this output below, is because nothing is being sent (as above).

local ident (addr/mask/prot/port): (192.168.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (172.16.0.0/255.252.0.0/0/0)
#pkts encaps: 255682246, #pkts encrypt: 255682246, #pkts digest: 255682246
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

And also check NAT is not configured (I assume it's not), traffic to/from those networks above should be denied - if NAT is configured.

[MHM Cisco World]

friend the output you share must be for hub not for spoke.
Hub connect two Spoke 
hub receive the packet from IPSec tunnel from one Spoke and forward it to other Spoke through other tunnel. 

what is the Issue here I think that GM is not learn each prefix direct, it learn prefix from the KS. 
only deny routing protocol to pass through the tunnel between GM-KS 

[Rob Ingram]

GETVPN is not hub and spoke.

[MHM Cisco World]

I know it full mesh BUT to make it full mesh you must to allow routing protocol to bypass the IPsec to KS 
here I think he pass the routing protocol between GM through the tunnel toward KS 
this prevent GM to direct connect and hence it become hub and Spoke not full mesh. 

he can confirm that by show ip route in KS and GM.

[whistleblower14]

@MHM Cisco World sorry, but I don´t know what you mean with all of your comments because the routing between the GM devices is MPLS and so the communication is any-to-any here - no traffic routing Hub&Spoke...

I´ve done some more reading through documentations and blogs but unfortunatley till yet I could`nt find an example which shows Crypto-ACL entries similar to mine - only either "permit ip any any" or "permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255"... in that cases the encaps- and decaps statistics output in show crypto ipsec sa are among themselves

but I´ve found an interessting post which maybe explains why the output looks like it does in my case when the ACL contains such entries:
permit ip 172.16.0.0 0.3.255.255 192.168.0.0 0.0.255.255
permit ip 192.168.0.0 0.0.255.255 172.16.0.0 0.3.255.255

Access-list in Traffic Encryption Policy

The permit entries in the access control list (ACL) for encryption policy should include the subnets which must be encrypted. The maximum number of lines in a traffic ACL is 100. Note that each permit statement in the KS ACL results in a SA on the GM, so the number of permit entries should be limited to minimize the SA database (SADB) on the GM. As mentioned, it is possible to add a single “permit ip any any” entry in the ACL to encrypt all

so I guess it works as designed

[MHM Cisco World]

first can you confirm that GM-GM routing is running ??
MPLS is Label you need to confirm that iBGP and eBGP is run between GM 

[whistleblower14]

yes, i can confirm that GM-GM routing is working fine, as I´ve trying to say - for me it looks like the encryption/decryption is working - the "only thing" that makes my brain crackle is the show output, which I don`t understand why this is´nt just the same as in the classic one?!

[MHM Cisco World]

from cisco doc.

remark >> exclude routing protocol used for Layer 2 WAN
deny eigrp any any

GET VPN Technology Design Guide - August 2014 (cisco.com)

[whistleblower14]

I´d like to give you an update about on that post!
Because I was`nt able to find an explantation about the output of the "show crypto ipsec sa", I opened a TAC-Case and discussed this topic with a Cisco Engineer - we`re still investigating - but regarding the TAC-Engineer this looks like a cosmetic issue!

[MHM Cisco World]

I will run lab play with setting and hope get same results' at this point we can know it cosmetic or not.

Thanks

[whistleblower14]

@MHM Cisco World many thanks for the effort, I thank you very much! I´ll keep the post updated!