Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Spoke to spoke VPN connectivity

Hello All,

I am familiar with u-turn for remote access and site to site vpns with dynamic public addressing, ie that site has to initiate the connection, so the crypto acl at the hub is fairly simple. However what if both spoke sites have static addressing and either can initiate a connection to the other? Can someone clarify for me if the configuration (crypto acl and nonat) for the hub site is correct?

Hub - 10.10.40.0/24

Site A - 10.10.20.0/24

Site B - 10.10.30.0/24

Hub

------

access-list crypto_acl extended permit ip 10.10.40.0 255.255.255.0 10.10.20.0 255.255.255.0
access-list crypto_acl extended permit ip 10.10.40.0 255.255.255.0 10.10.30.0 255.255.255.0
access-list crypto_acl extended permit ip 10.10.30.0 255.255.255.0 10.10.20.0 255.255.255.0

access-list crypto_acl extended permit ip 10.10.20.0 255.255.255.0 10.10.30.0 255.255.255.0

access-list nonat extended permit ip 10.10.40.0 255.255.255.0 10.10.20.0 255.255.255.0
access-list nonat extended permit ip 10.10.40.0 255.255.255.0 10.10.30.0 255.255.255.0
access-list nonat extended permit ip 10.10.30.0 255.255.255.0 10.10.20.0 255.255.255.0

access-list nonat extended permit ip 10.10.20.0 255.255.255.0 10.10.30.0 255.255.255.0

Site A

---------

access-list crypto_acl extended permit ip 10.10.20.0 255.255.255.0 10.10.30.0 255.255.255.0
access-list crypto_acl extended permit ip 10.10.20.0 255.255.255.0 10.10.40.0 255.255.255.0

access-list nonat extended permit ip 10.10.20.0 255.255.255.0 10.10.30.0 255.255.255.0
access-list nonat extended permit ip 10.10.20.0 255.255.255.0 10.10.40.0 255.255.255.0

Site B

---------

access-list crypto_acl extended permit ip 10.10.30.0 255.255.255.0 10.10.20.0 255.255.255.0
access-list crypto_acl extended permit ip 10.10.30.0 255.255.255.0 10.10.40.0 255.255.255.0

access-list nonat extended permit ip 10.10.30.0 255.255.255.0 10.10.20.0 255.255.255.0
access-list nonat extended permit ip 10.10.30.0 255.255.255.0 10.10.40.0 255.255.255.0

3 REPLIES
New Member

Re: Spoke to spoke VPN connectivity

Are you saying this is not working? If you are doing u-turn then wouldn't your ACL have to be based on the address that you are NATing at the HUB for u-turn?

Re: Spoke to spoke VPN connectivity

This is not an active deployment I just wanted to clarify if the crypto acl at the hub is correct. This is for a L2L vpn so I am not sure what you are referring to when you speak of "natting at the hub". Apart from natting internal addresses to access the Internet a no nat acl is required to ensure that traffic is exempted from nat when traversing the tunnel.

I just want to know if both directions are required at the hub Site A to B, Site B to A (crypto acl and no nat) or is one direction enough. I figure both directions are required if Site A can initiate a connection to Site B and vice versa. Can someone clarify please, thanks.

New Member

Re: Spoke to spoke VPN connectivity

Nevermind I was thinking that spoke to spoke uturns were the same as uturns on a remote client VPN in which case you need to NAT the traffic. This does not apply in this case. On that note as far as I can tell you have the access list correct. Sorry for the confusion.

158
Views
0
Helpful
3
Replies
CreatePlease to create content