encap decap counters

[WILLIAM STEGMAN]

I'm looking at the encap and decap counters on a tunnel that is up (my side is IOS and the client side is checkpoint).  The tunnel is up, traffic is passing and users are accessing services on my side, but I'm put off by the counters.  The first line of the show cry ips sa peer command displays the network to network traffic and shows all the encaps, but that is followed by network to host/client stats and they each show only the decaps.  Below is an example of the first two lines, I left out the rest of the hosts.  Is there something wrong with my config, or am I just not understanding the output of the sh cry ips sa peer command and its counters?

thank you   

VPN-RTR-Primary#sh cry ip sa peer x.x.x.6

interface: GigabitEthernet0/0

    Crypto map tag: outside_map, local addr x.x.x.254

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (10.21.40.0/255.255.255.192/0/0)

   remote ident (addr/mask/prot/port): (10.175.138.0/255.255.255.0/0/0)

   current_peer x.x.x.6 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 272744465, #pkts encrypt: 272744465, #pkts digest: 272744465

    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 0, #recv errors 0

     local crypto endpt.: x.x.x.254, remote crypto endpt.: x.x.x.6

     path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0

     current outbound spi: 0x64AA772D(1688893229)

     PFS (Y/N): N, DH group: none

     inbound esp sas:

      spi: 0xB5AC466F(3047966319)

        transform: esp-3des esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 4995, flow_id: Onboard VPN:2995, sibling_flags 80000040, crypto map: outside_map

        sa timing: remaining key lifetime (k/sec): (4201536/3441)

        IV size: 8 bytes

        replay detection support: Y

        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

      spi: 0x64AA772D(1688893229)

        transform: esp-3des esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 4996, flow_id: Onboard VPN:2996, sibling_flags 80000040, crypto map: outside_map

        sa timing: remaining key lifetime (k/sec): (4200664/3441)

        IV size: 8 bytes

        replay detection support: Y

        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (10.21.40.0/255.255.255.192/0/0)

   remote ident (addr/mask/prot/port): (10.175.138.63/255.255.255.255/0/0)

   current_peer x.x.x.6 port 500

     PERMIT, flags={}

    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

    #pkts decaps: 522628, #pkts decrypt: 522628, #pkts verify: 522628

[m.kafka · Accepted solution]

This is most likely a "specialty" of the oposite chekpoint. Some IPsec implemetations might try to establish separate phase2 security associations for each IP address resulting in /32 remote idents on your side. This is OK with IPsec standards and compatible with the IOS implemettion of IPsec.

This is the IOS crypto-map command, which does something similar: "set security-association level per-host"

http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_s2.html

If you are curious you can follow the IKE pahse2 negotiation to see more details about it (It should be "debug crypto ipsec" as far as I remember.

I think, it's nothing to be concerned about unless you run out of security associations.

Rgds,

MiKa

[Marcin Latosiewicz]

Just to add to this.

Having lots of IPsec SAs is definately not ideal, it will impact scalability and CPU (via rekey).

Best practice is to aggregate your IPsec traffic selectors.

[WILLIAM STEGMAN]

Marcin, do I have that option though since the customer is using Checkpoint?  My IPSec traffic list is an acl that uses the networks, i.e.

10 permit ip 10.21.40.0 0.0.0.63 10.175.138.0 0.0.0.255

and there's is a mirror acl.  Is there something else I could to to aggregate my IPSec traffic selectors?

thank you

[Marcin Latosiewicz]

My _guess_ is that checkpoint is starting quick mode exchange and ASA is accepting them because it's falling under dynamic crypto map.

I'm assuming those because I do not know your config and or software version.

We've dealt with something like this before, let me try to find it back.

Can you just give me the version on ASA side?

M.

[Marcin Latosiewicz]

I did find the setting MiKa was talking about (on CP side)

I'm not sure if we want to address this on ASA, it might break more than it fixes :-)

[WILLIAM STEGMAN]

I'm running this tunnel off IOS, 15.2(4)M2.  I thought I read somewhere that IOS typically shows the SAs for each host, which is very different from an ASA.  It's hard for me to see a difference with the other tunnels  running on the same router.  There's a mix of Juniper, Checkpoint, and  ASA, and the Juniper and ASA customers PAT their clients to one IP address, so there's only one IPSec SA.  However, the other Checkpoint customers (all which do not NAT their clients) stats all look the same as I first described in the original post, which coroborates Mika's understanding.    

thanks

[m.kafka]

Marcin, it's most likely not a dynamic crypto map but a standard behavior and the security association is created under the same crypto map sequence.

An incoming phase2 (resp. child-sa) request will be accepted if the remote/local idents are both permitted (in other words if the incoming request is for a "subnet" of your crypto-acl). This behavior is well documented and a little bit different to dynamic crypto maps which are configured with the keyword "dynamic" on your crypto map entry.

Rgds,

MiKa

Addendum @Marcin, The screen-shot: yes that's what I had to deal with on some projects

[Marcin Latosiewicz]

I have not see a static crypto map entry accepting a subset of ACL defined, but I can't claim to have seen all the scenarios out there.

"show crypto ipsec sa det peer x.x.x.6" would tell us a bit more about my crypto map assumptions :-)

But I think at this stage we all agree CP config needs to be adjusted.

[m.kafka]

Hi Marcin,

+1 from me, the Checkpoint should be be reconfigured if "pairwise SAs" are not urgently needed.

About the crypto-acl subset: I tried it a couple of times when teaching a class and it works good for incoming negotiations, outgoing negotiations will not be possible because the sent local/remote ident will be a "superset" instead of a "subset" at the peer.