Send errors on IPSec VPN

hegleran · ‎03-08-2010

First, I have attached a diagram to hopefully provide a little clarity to my problem. I have a location, which I will call my main location for the purpose of this issue that has multiple VPN solutions running on it:

A DMVPN for connectivity to the WAN

A remote access VPN for teleworker clients to connect

A site to site VPN that connects to a third party datacenter for access to a private hosted application.

The DMVPN is working as expected

The remote access VPN is working as expected except for the issue I am about to describe

The site to site VPN is working as expected for except for the issue I am about to describe

Problem:

Remote access users cannot access the hosted application through the site to site VPN tunnel, however they can access other services, such as those hosted on the LAN of the main location, and services available over the DMVPN WAN.

LAN users are able to access the app server across the site to site VPN, so I know this tunnel is established and working.

My ipsec security association recognizes the subnet of my remote access users (10.151.171.0/24):

interface: GigabitEthernet0/1
Crypto map tag: VPN_MAP, local addr A.B.C.D

   protected vrf: (none)
   local ident (addr/mask/prot/port): (10.151.171.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (W.X.Y.Z/255.255.255.240/0/0)
   current_peer L.M.N.O port 500
     PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #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 35, #recv errors 0

However, notice the send errors.

I see the traffic matching the acl for the interesting traffic to the remote application server sourced from the remote access VPN users:

Extended IP access list 199
10 permit ip 10.171.0.0 0.0.255.255 W.X.Y.Z 0.0.0.15 (6095009 matches)
20 permit ip 10.151.171.0 0.0.0.255 W.X.Y.Z 0.0.0.15 (56 matches)

So this verfies that the traffic is being received from the remote access VPN users by the main location router. However the router then, is not encapsulating and encrypting the traffic and sending it out, but rather it is generating send errors.

I also have an entry to bypass this traffic from NAT, however I see no matches on the entry:

12 deny ip 10.151.171.0 0.0.0.255 W.X.Y.Z 0.0.0.15

It should be noted that the interface that the remote access VPN, and the site to site VPN terminates on is the same interface - Gig0/1. They are both built as entries of the same crypto map. I had thought that this may be a split horizon issue, since I'd be hairpinning the interface, however disabling split horizon, removing the crypto map from the interface and reapplying it did not resolve the issue.

The remote end of the site to site tunnel confirmed that they added the 10.151.171.0/24 subnet to their interesting traffic list, just as I added that as a source of my interesting traffic. Being as though I am not even encapping/encrypting traffic on my end, out to the site-to-site tunnel, I believe the trouble to be on my end. On the diagram you will see arrows indicating the traffic flow that is experiencing this issue. Does any one have any thoughts as to why this is occuring?

jdcarpenter · ‎07-16-2012

I'm experiencing basically the same issue, except I'm using just a standard GRE tunnel instead of DMVPN in your scenerio.

Did you find a resolution to this?

Thanks

donlerche · ‎12-09-2012

I was having the same issue and when I found this thread thought great lets look at the solution - but the solution hasn't been given so had to work through myself and found out why it wasn't working for me. Hopefully my answer will help others having similar issues - judging by the number of views on the discussion (2646 at time of writing) this is a common problem.

OK, the biggest clue is if you do a "show crypto ipsec sa" and this will list all tunnels you have configured. You should notice that there is a entry for each line you have in the crypto map you are using to identify "interesting" traffic, the key is that each tunnel entry has a "local" and "remote" identifier corresponding to the "source" and "destination" entry in the matching line in crypto map acl. THESE NEED TO MATCH AT THE OTHER END (but in opposite direction) for the tunnel to be established.

In my case, I had a different subnet mask in the ACL for the source subnet at one end to the destination in the crypto map at the other end, so even though the crypto map was showing hits on identifying the interesting traffic, the "local" identifier at one end didn't match the "remote" identifier at the other end. Simple fix once you know this :¬)

Hope this helps