cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
422
Views
0
Helpful
3
Replies

VPN users needs access to all L2L VPN Segments

luckygt21
Level 1
Level 1

Client has a Cisco ASA 5510 with 4 L2L VPN's all using 5505's

The L2L connect to the "outside" interface as do the VPN Users (I'm leary of this

The VPN Users need access to the "inside" networks and all L2L subnets.

The VPN User has its own subnet (192.168.168.0/24( seperate from the Local LANs (172.16.0.0/16)

When the Users VPN in they can get to all the subnets connected to the inside interface but none of the L2L subnets

I have verified that the UserVPN Subnet is in the crypto acls and in the route statements of all L2L 5505s

Am I missing something?

3 Replies 3

Richard Burts
Hall of Fame
Hall of Fame

For one remote site to access resources at another remote site requires the ASA to forward traffic back out the same interface it was received on. This is sometimes referred to as hair pinning and the ASA does not permit it by default. There is a command for same security intra interface. You should put command into your config and let us know if the behavior changes.

HTH

Rick

Sent from Cisco Technical Support iPhone App

HTH

Rick

Thanks for the response Richard,

I should have mentioned in the OP that the "same-security-traffic permit intra-interface" was in the config.

I wish I could post the config, however the owner of the company wishes to not have that posted.

Yes it would have been helpful to know that the same-security-traffic intra-interface was already in the config.. But I think it was a good place to start. And it will make it a bit more difficult if you are not able to post configs. But we will try again to suggest a problem and the solution for it.

The L2L VPN has an access list that identifies traffic to be carried in the VPN tunnel. Typically that access list will permit traffic with a source address in the remote subnets and a destination in the HQ subnets. I am guessing that the access list does not permit the Remote Access subnet of 192.168.168.0. Try adding the RA subnet to the access list (on both the HQ and the remote site) and tell us if the behavior changes.

HTH

Rick

HTH

Rick