cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1489
Views
5
Helpful
5
Replies

Hub-and-spoke topology (between vpn´s site-to-site connections) ?

TiagoRebelo
Level 1
Level 1

Hi all,

I have a friend that have in his company an ASA5505 at central point and about 5 remote sites connected via Vpn site-to-site.

All tunnels are up and reach the central network.

The only traffic that pass throw the tunnel is the traffic with the ASA local network destination.

My friend asked me what it needs to reach from one Vpn remote site to another Vpn remote site, passing throw the ASA5505 central site.

The ASA5505 can reach all remote networks throw the tunnels.

Can anyone give me a little brief what it needs for the ASA to route traffic between the VPN´s tunnels?

Does it need static routes on the remote sites to advertise the other remote sites ?

Best Regards

1 Accepted Solution

Accepted Solutions

Herbert Baerten
Cisco Employee
Cisco Employee

Hi Tiago,

you will need to do 3 things basically:

On the hub you will need to configure:

same-security-traffic permit intra-interface

(this allows traffic to go out of the same interface  that it came in on - in your case traffic between the spokes will enter  on the outside and will go back out on the outside).

Then,  on the hub as well as on the spokes, you need to add all the  spoke-to-spoke traffic to the crypto ACL, and to the nat exemption ACL.

Depending  on how your addressing scheme, you may be able to aggregate to avoid  making the ACLs very large (for 5 spokes I suppose it is still  manageable though).

No routes should be needed on the spokes or the hub (unless the vpn  tunnels are taking a different path than your regular internet traffic,  I'm assuming this is not the case).

Let me know if you need more details.

hth

Herbert

View solution in original post

5 Replies 5

Herbert Baerten
Cisco Employee
Cisco Employee

Hi Tiago,

you will need to do 3 things basically:

On the hub you will need to configure:

same-security-traffic permit intra-interface

(this allows traffic to go out of the same interface  that it came in on - in your case traffic between the spokes will enter  on the outside and will go back out on the outside).

Then,  on the hub as well as on the spokes, you need to add all the  spoke-to-spoke traffic to the crypto ACL, and to the nat exemption ACL.

Depending  on how your addressing scheme, you may be able to aggregate to avoid  making the ACLs very large (for 5 spokes I suppose it is still  manageable though).

No routes should be needed on the spokes or the hub (unless the vpn  tunnels are taking a different path than your regular internet traffic,  I'm assuming this is not the case).

Let me know if you need more details.

hth

Herbert

Hi Herbert,

Thanks for your reply, i understanded your brief explanation.

Best Regards,

Tiago

ShaunGreen
Level 1
Level 1

Hi Guys,

I've been struggling with this one and I have exactly the same setup, any idea what I'm missing.

I've got a central site with a ASA 5505 8.3(1) and 12 remote sites (I'm testing with just two remote sites at the moment).

Remote sites are 886's.

I've set up and had working point to point static IPSEC tunnels for the last 5-6 months, passing VOIP.

The client has now decided they want spoke to spoke VOIP and hence the need for spoke to spoke IPSEC tunnels.

I've tried to read the following document but that hasn't helped much:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00804675ac.shtml

I've seen your post and can confirm the following:

Configured same-security-traffic permit intra-interface on the central ASA.

I have the config for remote site A:

crypto map outside_map 2 match address outside_2_cryptomap

crypto map outside_map 2 set pfs group1

crypto map outside_map 2 set peer 2.2.2.2

crypto map outside_map 2 set transform-set ESP-3DES-SHA

access-list outside_2_cryptomap extended permit ip object CENTRAL object SITEA

access-list outside_2_cryptomap extended permit ip object SITEA object SITEB

access-list outside_2_cryptomap extended permit ip object SITEB object SITEA

I have the config for remote site B:

crypto map outside_map 4 match address outside_4_cryptomap

crypto map outside_map 4 set pfs group1

crypto map outside_map 4 set peer 3.3.3.3

crypto map outside_map 4 set transform-set ESP-3DES-SHA

access-list outside_4_cryptomap extended permit ip object CENTRAL object SITEB

access-list outside_4_cryptomap extended permit ip object SITEB object SITEA

access-list outside_4_cryptomap extended permit ip object SITEA object SITEB

On the remote sites I have a default route out of a dialer interface with a (working) crypto map which was just for voice traffic from the remote site to the central site. I've now added the voice traffic destined to the other remote site and I can see hits on the ACL.

I can also see on the remote sites using show crypto ipsec sa that traffic is being encrypted from one remote site to the other and visa versa, but nothing gets decrypted.

When I remove the crypto map statements in bold (above) from the central site I see send errors on the remote sites when issuing show crypto ipsec sa.

Also I've added the following statements for NAT:

nat (inside,outside) source static SITEA SITEA destination static SITEB SITEB

nat (inside,outside) source static SITEB SITEB destination static SITEA SITEA

Now the original point to point IPSEC tunnels were set up using ASDM and they have been woring fine for quite a few months so I assume that side of things is okay, but when I try and add spoke to spoke IPSEC tunnels I just can't get it up and running.

Am I missing something?

Hi Graces,

try:

nat (outside,outside) source static SITEA SITEA destination static SITEB SITEB

nat (outside,outside) source static SITEB SITEB destination static SITEA SITEA

since both siteA and siteB are on the outside...

also, these 2 lines are incorrect and should be removed:

access-list outside_2_cryptomap extended permit ip object SITEA object SITEB

access-list outside_4_cryptomap extended permit ip object SITEB object SITEA

hth

Herbert

Hi Herbert,

Ahhh, completely missed the nat mistake.

Yep, I had the two acl's around the wrong way, now you've pointed it out, makes perfect sense.

Excellent, great help, thanks a million!

quick edit..should have added, made the changes you pointed out...worked a treat!

Simon.