Showing results for 
Search instead for 
Did you mean: 


SSL VPN client talking across IPSec tunnel

Is it possible for a computer connected via Anyconnect to talk to another site connected via IPSec site-to-site tunnel?  We have a user that wants to VPN in and acess a desktop in a remote city.  Originally the remote city was connected as EasyVPN.  I read that it is not possible for them to talk, so we changed the setup to a site-to-site IPSec tunnel.  That site can talk to the main site fine across the VPN tunnel, and the SSL VPN clients can talk to the main site fine.  But I cannot figure out how to make the SSL client talk to the remote IPSec site.  Is this even possible, or are we just missing something simple?  I have checked the no-nat list, the interesting traffic list, etc. and all that is fine.

Edit for more info:  We have permit intra-interface enabled, VPN clients can browse the web, and we have all the subnets in the encryption ACL.

Marvin Rhoads
VIP Community Legend

Yes it's certainly possible.

How are you pushing routes to the client? Typically there is a line like:

split-tunnel-network-list value

in the group-policy governing your SSL VPN clients. The access-list referenced would have to include the remote network ranges you wish for the SSL Client to be able to access.

We are tunneling all networks, so split tunneling should not be an issue.  I should have put that in the original post, my bad!

Ok, that was the easy theory shot down.

Do you have "same-security-traffic permit intra-interface" and the SSL VPN client address pool included in the encryption domains at both ends of the site-site VPN?

Edit - also don't neglect NAT exempt for the remote access traffic that is trying to go back out via the site-site VPN.

Haha, no problem.  We do have intra-interface set and the clients can browse the web.  The VPN client pool IS in the encryption ACL on both ends, and we have those addresses set to "no-nat" as well. 

OK, that covers all the obvious causes.

Have you tried running packet-tracer on the ASA to see how it believes it should handle the flow?

Once your verify the remote access VPN traffic is being handled as designed by their head end ASA, more detailed tools would include examining your IPsec SAs at both ends to verify that an SA is being built to include the remote access client subnet and target remote site subnet. If not then debugs of the crypto ipsec activity may be in order.

I have tried running packet tracer, but I can never figure out which interface to put it on when testing the VPN side.  I do not get any IPSec SA when I send test traffic, so that might be where I need to look.  I am trying to get access to a computer at the remote site for testing.  I will post updates as we learn more.  Thanks for your help Marvin!!!

Ok, so if I do a trace from the remote site ASDM trying to talk to the client, I get an SA after the 2nd attempt.  I get an SA on both sides but no encaps/decaps.  I assume the SA is building due to the packet tracer, but the actual traffic I am trying to send is not doing it.


Many years after i'm experiencing the same problem.

I have a vpn site2site that is working correctly. I need that anyconnect clients arriving from one site can reach the othe site of vpn. The strange thing is that this situation works with ipsec vpnclient...

Is there a solution for this problem?


So basically,

You connect from an Anyconnect client to the HQ ASA and try to go U-turning to the other site of a L2L VPN?

But it does not work right?

What's the version you are running on the ASA?

Can You post the configuration?

Remember to rate all of the helpful posts.

For this community that's as important as a thanks.

Julio Carvajal
Senior Network Security and Core Specialist

Problem solved upgrading firewall release from 8.4.3 to 8.4.6

I was sure about the configuration..

Thanks jcarvaja.

Hello Sr,

Great to hear that, Some kudos to you

Can you mark the question as answered so future users can learn from this,

Remember to rate all of the helpful posts.

For this community that's as important as a thanks.

Julio Carvajal
Senior Network Security and Core Specialist
Recognize Your Peers
Content for Community-Ad