Remoe VPN client cannot get across L2L (site-to-site) tunnel after making connection.
The problem is at the remote client, which is using Cisco VPN client.
Remote client connection is made fine to [ASA1].
Problem is that remote client does not know route to network LAN2 and dumps traffic off to its default gateway rather than directing it to [ASA1] for forwarding to [ASA2]. ([ASA1] and [ASA2], of course, know about each other.)
Cisco VPN client has capability of being "told" subsequent routes (Status->statistics->Route details).
As I see it, the client must get this info from the ASA to which it makes its remote VPN connection.
The advice I am hoping for is the CLI or ASDM syntax I need to apply to get the ASA to provide this route information.
As long as you are not split tunneling the traffic from the client it should arrive at ASA1. Then it is up to ASA1 to send the traffic over the tunnel to ASA2. You must define this traffic as interesting in ASA1 and ASA2.
You also need to add nat exemption on ASA2 for the vpn client subnet.
Also, add this to ASA1
same-security-traffic permit intra-interface
Adam, thank you for the comprehensive reply ... unfortunately it's not working.
1. The statements you list above were already there to facilitate the L2L.
2. I turned-off split tunneling (or think I did) and ran a test ... no joy.
This took me back to my original premise that the remote client doesn't know how to send the traffic (bound for L2L) down the remote tunnel and dumps it of to its default gateway (to the WWW).
If you're willing to look at it, I have attached screen shots of the client ipconfig and the Cisco VPN client - showing its routes.
The ipconfig seems to say that the remote connection has its default gateway, and the tunnel has none.
The VPN client screen shows it knows a route (192.168.5.0/24) to the ASA, but nothing beyond. The ASA does, in fact, know about the network (10.64.0.0/16) at the other end of the L2L.
As I see it, if I can find a way to get the ASA to advertise this route to the VPN client, the problem might be solved. The client will then know to forward the traffic to the ASA instead of dumping it to the default gateway.
Just set your split tunnel to tunnel all or add the 10.64.0.0/16 network to your split tunnel acl.
Your current split tunnel acl probably looks something like...
access-list split_tunnel permit ip x.x.x.x x.x.x.x 192.168.5.0 255.255.255.0
access-list split_tunnel permit ip x.x.x.x x.x.x.x 10.64.0.0 255.255.0.0
10.64.0.0/16 should then be listed in the secured routes.
I really appreciate the effort you have gone thru.
I did discover what you list here over the weekend by sledgehammer method. The routes are listed, but I still can't get connection.
By viewing debug, I can see the traffic now getting to the ASA (instead of lost) but nothing comes back. Additional sledgehammering, I tried NAT exemptions, etc. to no avail.
You've been more helpful than TAC, who hasn't gotten me as far as your advice.
Fortunately, I can work around the problem by severing the VPN connection and making a new one to the other end ... it's just inconvenient.
Again, thanks for the help. I'm just going to ask TAC for an escalation.