Can't access specific subnets over site to site vpn via remote access vpn

support · ‎08-13-2010

We have an ASA 5520 with a site to site vpn to another location. Our internal network is 10.1.0.0 and the other location is 192.168.0.0. We have some specific 192.168.x.x subnets setup in split tunneling so that they can be accessed via remote acccess vpn. We have turned on "same-security-traffic permit intra-interface" to allow traffic to go directly over the site to site from remote access vpn. Recently we added additional subnets,

192.168.29.0, 192.168.39.0 and 192.168.79.0 to the split tunneling so they can be accessed remotely. For some reason it is not working. I cannot ping for example 192.168.29.3 while connected via remote access vpn. We have no problem accessing from within the corporate network. Traceroute does not show anything and I wouldn't think there would be any routes needed since it is entering and exiting the same interface. The subnets we added previously are still working just fine (192.168.220.0, 192.168.230.0, etc)

I am not sure why the recently added subnets will not work. Anyone have any thoughts?

Jennifer Halim · ‎08-14-2010

Base on the described configuration, it should have worked. If the crypto ACL is configured as 192.168.0.0/16 subnet, and split tunnel ACL has included the new 192.168.x.x subnets, then it should work just fine.

One possibility is the new subnets do not know how to route the traffic back towards the remote vpn client pool subnet. Do you know where it's actually breaking? Is the new 192.168.x.x subnets behind another firewall? directly connected to the existing firewall? perhaps NAT exemption towards the remote vpn client pool has not been included?

rhysjevzv599 · ‎12-25-2010

Jennifer Halim wrote:

Base on the described configuration, it should have worked. If the crypto ACL is configured as 192.168.0.0/16 subnet, and split tunnel ACL has included the new 192.168.x.x subnets, then it should work just fine.

One possibility is the new subnets do not know how to route the traffic back towards the remote vpn client pool subnet. Do you know where it's actually breaking? Is the new 192.168.x.x subnets behind another firewall? directly connected to the existing firewall? perhaps NAT exemption towards the remote vpn client pool has not been included?

It is exactly what I need, Thanks for your sharing! I got more deep understanding about this part.