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
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):
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
#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?