L2L IPsec issue: 0 decrypted packets!!!

[fntowo2009]

Hi,

We implemented a l2l IPSec solution between the HQ and a remote branch. Since the latest is a vessel, we opted for the Dynamic-to-Static l2l Ipsec solution using two ASAs. However, the solution fails at some ports. In fact, the tunnel is established and packets are encrypted on the remote ASA. However, no packets are decrypted... The HQ doesn't see any incoming encrypted packets. It looks like something in between does prevent the IPSec packets from reaching the HQ...

How could we ensure that the solution always works regardless of any ACL or NAT in between?

Below are excerpts of the "sh crypto ipsec sa" cmd for a positive and a negative outcome as well as the Remote-ASA IPsec config.

Remote-ASA# sh crypto isakmp sa

interface: outside
    Crypto map tag: CMAP, seq num: 10, local addr: 172.16.1.215

      access-list vpn extended permit ip 10.240.192.0 255.255.255.0 10.0.0.0 255.0.0.0
      local ident (addr/mask/prot/port): (10.240.192.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)
      current_peer: 146.40.75.33

      #pkts encaps: 28, #pkts encrypt: 28, #pkts digest: 28
      #pkts decaps: 15, #pkts decrypt: 15, #pkts verify: 15
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 28, #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.: 172.16.1.215, remote crypto endpt.: 146.40.75.33

Remote-ASA# sh crypto isakmp sa

interface: outside
    Crypto map tag: CMAP, seq num: 10, local addr: 168.240.6.11

      access-list vpn extended permit ip 10.240.192.0 255.255.255.0 10.0.0.0 255.0.0.0
      local ident (addr/mask/prot/port): (10.240.192.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)
      current_peer: 146.40.75.33

      #pkts encaps: 45, #pkts encrypt: 45, #pkts digest: 45
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 28, #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.: 168.240.6.11, remote crypto endpt.: 146.40.75.33

Remote-ASA config

access-list vpn extended permit ip 10.240.192.0 255.255.255.0 10.0.0.0 255.0.0.0

access-list nonat extended permit ip 10.240.192.0 255.255.255.0 10.0.0.0 255.0.0.0

global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0

crypto ipsec transform-set esp-3des-sha esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map CMAP 10 match address vpn
crypto map CMAP 10 set pfs group1
crypto map CMAP 10 set peer 146.40.75.33

crypto map CMAP 10 set transform-set esp-3des-sha
crypto map CMAP 10 set phase1-mode aggressive group1
crypto map CMAP 10 set reverse-route
crypto map CMAP interface outside
crypto isakmp identity hostname
crypto isakmp enable outside
crypto isakmp policy 65535
authentication pre-share
encryption 3des
hash sha
group 1
lifetime 86400
no crypto isakmp nat-traversal

tunnel-group 146.40.75.33 type ipsec-l2l
tunnel-group 146.40.75.33 ipsec-attributes
pre-shared-key ***

Thanks for your help!

Franc

[Federico Coto Fajardo · Accepted solution]

Hi,

The first output shows both packets encrypted/decrypted on the remote ASA.

At that point the VPN was working fine? What was different?

The second output shows packets encrypted on the remote ASA but none decrypted.

You mentioned the HQ site did not show decrypted packets either.

It seems that the remote ASA sends traffic through the tunnel, but they never reached the HQ site.

This could happen when there's a route problem, NAT problem, or some sort of VPN filter.

To understand this better please explain what was the difference between the first and the second scenario.

Federico.

[fntowo2009]

Federico,

Thanks for your prompt feedback!

As stated, the remote office is a vessel and thus moves from port to port. The difference between both outputs lies in the use of different ISPs. Obviously, something prevents the encrypted packets from reaching the HQ ASA. So, I was wondering whether I could overcome whatever barriers are on the IPSec path...

Thanks,

Franc

[Federico Coto Fajardo]

The IPsec tunnel is always established using UDP 500.

The actual traffic is sent in ESP (IP protocol 50).

For a site-to-site these are the ports you should care about.

If there's a NAT device in between, you would normally require UDP 4500 as well.

You can enable IPsec/TCP that uses TCP 10000 by default.

Federico.

[fntowo2009]

Federico,

Thanks for your input!

I solved the issue by enabling NAT-Traversal with "crypto isakmp nat-traversal".

Thanks,

Francos