Traffic does not flow with Crypto Map in Protect Mode?

[saabqmacs]

Hello:

I set up a site-to-site tunnel and added in the associated Crypto Map (see static 6 below). However, in the Protect mode, I cannot ping the far-end from the CitrixServers or vice-versa. However, if I change to Do Not Protect, then I can ping from CitrixServers to far-end.

Static 6 is simply a clone of static 5 (which works just fine), but for a new customer (site-to-site tunnel).

Questions:

1. Why can't I ping in Protect mode?
2. How can I debug this issue further? Everything is set up properly, but I just cannot ping from CitrixServers to far-end in Protect mode, but it works fine in Do Not Protect mode.
3. What is the harm in leaving this traffic in Do not Protect mode, given that there is a site-to-site tunnel. Won't the tunnel traffic automatically be encrypted?

Any help is appreciated. Thank you!

[Rahul Govindan]

Protect vs Do not Protect is basically permit vs deny in the crypto ACL. If you hit Protect, traffic will match that ACL be sent across that tunnel. Do Not protect will allow you to skip that tunnel and match another one you have at the bottom.

In your case, its strange that it works when you have Do not Protect set, which might mean that there might be another tunnel that the working traffic matches. Check the output of "show crypto ipsec sa peer <peer ip address>" when the Do not protect is enabled. It should show which crypto map entry it used to build the tunnel in the first place. I see this happening, when the peer initiates the tunnel negotiation and it hits our dynamic entry right at the bottom because of some mistmatched config.

[saabqmacs]

I do have a dynamic entry in the Crypto Maps (highlighted in blue below):

Here is the output of the show crypto ipsec sa peer command. It shows the SYSTEM_DEFAULT_CRYPTO_MAP is being used (highlighted in red). What configuration mismatch could be causing this?

VPN-ASA# show crypto ipsec sa peer 2.2.2.2
peer address: 2.2.2.2
    Crypto map tag: SYSTEM_DEFAULT_CRYPTO_MAP, seq num: 65535, local addr: 1.1.1.1

      local ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)
      remote ident (addr/mask/prot/port): (10.150.40.0/255.255.255.0/0/0)
      current_peer: 2.2.2.2

      #pkts encaps: 69570, #pkts encrypt: 69570, #pkts digest: 69570
      #pkts decaps: 106152, #pkts decrypt: 106152, #pkts verify: 106152
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 69570, #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.: 1.1.1.1, remote crypto endpt.: 2.2.2.2

      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: 88FCFA29
      current inbound spi : EB7BD71B

    inbound esp sas:
      spi: 0xEB7BD71B (3950761755)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 5, }
         slot: 0, conn_id: 22695936, crypto-map: SYSTEM_DEFAULT_CRYPTO_MAP
         sa timing: remaining key lifetime (kB/sec): (4372347/2465)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0x88FCFA29 (2298280489)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 5, }
         slot: 0, conn_id: 22695936, crypto-map: SYSTEM_DEFAULT_CRYPTO_MAP
         sa timing: remaining key lifetime (kB/sec): (4373147/2465)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

[Rahul Govindan]

Exactly as I thought !! Usually its the wrong peer ip address configured or a lack of tunnel-group (Connection profile) for that peer ip address. The ASA will do a check to see if there a crypto map entry for that peer and if it does not find one, it will keep looking untill it find the dynamic one, which will accept any ip address.

You can run a debug crypto ikev1 127 on the CLI and clear the current tunnel so that it re-negotiates. You can then see what is the though process the ASA goes through to fall back into the dynamic map.

[mikebaisley]

Are you still having this issue? Basically, a 'Do not Protect' will continue until it finds a matching crypto map, if there is none - it will go to SYSTEM_DEFAULT_CRYPTO_MAP (Because of what 'ANY ANY' encompasses.

What do you see with a show crypto ipsec when you have protect mode on? Does the tunnel come up at all?

[saabqmacs]

The tunnel comes up fine. It is using the SYSTEM_DEFAULT_CRYPTO_MAP. I still dont know why it is using the Default cryptomap, but it is working, and traffic is flowing.

I can't clear this tunnel now, as there is live traffic on it. Perhaps in the future in some maintenance window.

Thanks everyone.