cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
723
Views
0
Helpful
2
Replies

5 Site VPN Routing

licensing
Level 1
Level 1

Hello all,

I kind of got thrown into this project without much lead in.  Basically we have 5 sites

Site A: HQ with ASA 5520

Site B: Remote with 5505 with L2L to Site A

Site C: Remote with 5505 with L2L to Site A

Site D: Remote with 5505 with L2L to Site A

Site E: Remote with 5505 with L2L to Site A

In an emergency situation, I had to get the phone systems running when a PTP T1 line was cut early by the client! I created a VLAN on each 5505 named Phone, and created individual L2L VPN Tunnels all going back to the HQs 5520.  All was good in the neighborhood, phones were talking to main PBX server at HQ, we could dial out and in no problem.  The problem lies with now the Phone Vender is telling us that we need routing between each and every site. We cannot dial in between each remote site without using the external number (whereas previously you could dial internal extensions to reach all other sites)

Site B needs to talk to the PBX at C,D, and E (obviously A as well but that's already working) and so on.

I have found topics discussing 2 remote offices that need routing, however, with 4 that all need routing to each other the configs are going to get very large and complicated very quickly.  There are already additional VPNs at the HQ 5520's that go elsewhere and a fair amount of security configurations, so the config is already pretty decently sized. 

Is there a better way to accomplish this, or should I start writing my configurations now?!

1 Accepted Solution

Accepted Solutions

m.kafka
Level 4
Level 4

If I understand your issue correctly you would need to configure a full list of VPN LANs on each of the VPN spokes and the hub.

E.g. on spoke B a crypto access list similar to:

permit ip B->A

permit ip B->C

permit ip B->D

permit ip B->E

the corresponding crypto ACL on the Hub for spoke A would be like:

permit ip A->B

permit ip C->B

permit ip D->B

permit ip E->B

repeat for each spoke accordingly.

So actually your crypto configuration would't grow, only the crypto ACLs.

You can work with object-groups to simplify the crypt ACLs, in that case:

Crypto ACL on hub B:

object-group VoIP-dst

  object A

  object C

  object D

  object E

object-group VoIP-src

  object B

permit ip VoIP-src VoIP-dst

And so on...

Just make sure that your config allows same-security-traffic intra-interface

View solution in original post

2 Replies 2

m.kafka
Level 4
Level 4

If I understand your issue correctly you would need to configure a full list of VPN LANs on each of the VPN spokes and the hub.

E.g. on spoke B a crypto access list similar to:

permit ip B->A

permit ip B->C

permit ip B->D

permit ip B->E

the corresponding crypto ACL on the Hub for spoke A would be like:

permit ip A->B

permit ip C->B

permit ip D->B

permit ip E->B

repeat for each spoke accordingly.

So actually your crypto configuration would't grow, only the crypto ACLs.

You can work with object-groups to simplify the crypt ACLs, in that case:

Crypto ACL on hub B:

object-group VoIP-dst

  object A

  object C

  object D

  object E

object-group VoIP-src

  object B

permit ip VoIP-src VoIP-dst

And so on...

Just make sure that your config allows same-security-traffic intra-interface

Thanks m.kafka, and sorry about the delayed response!

For anyone interested in exactly how it was done with a  real world example, I've modified the subnets, but modify with your  subnets.

*** Site A - HQ ***

same-security-traffic permit intra-interface

same-security-traffic permit inter-interface

object-group network VOIP-dst

network-object 10.10.1.0 255.255.255.0

network-object 10.10.2.0 255.255.255.0

network-object 10.10.3.0 255.255.255.0

network-object 10.10.4.0 255.255.255.0

object-group network VOIP-src

network-object 10.10.0.0 255.255.255.0

access-list outside_4_cryptomap extended permit ip object-group VOIP-dst 10.10.1.0 255.255.255.0

access-list outside_5_cryptomap extended permit ip object-group VOIP-dst 10.10.2.0 255.255.255.0

access-list outside_2_cryptomap extended permit ip object-group VOIP-dst 10.10.3.0 255.255.255.0

access-list outside_3_cryptomap extended permit ip object-group VOIP-dst 10.10.4.0 255.255.255.0

-------------------------------------

*** Site B - Remote ***

same-security-traffic permit intra-interface

same-security-traffic permit inter-interface

object-group network VOIP-dst

network-object 10.10.1.0 255.255.255.0

network-object 10,10.2.0 255.255.255.0

network-object 10.10.3.0 255.255.255.0

object-group network VOIP-src

network-object 10.10.4.0 255.255.255.0

access-list outside_1_cryptomap extended permit ip object-group VOIP-src object-group VOIP-dst

------------------------------------------------

*** Site C - Remote ***

same-security-traffic permit intra-interface

same-security-traffic permit inter-interface

object-group network VOIP-dst

network-object 10.10.4.0 255.255.255.0

network-object 10.10.1.0 255.255.255.0

network-object 10.10.3.0 255.255.255.0

object-group network VOIP-src

network-object 10.10.2.0 255.255.255.0

access-list outside_1_cryptomap extended permit ip object-group VOIP-src object-group VOIP-dst

.....

then repeated for additional sites.

I  then pinged across all sides, to and from each site.  The ping requests  failed at first, but once I pinged from each side to the other it  works. Everything has been working fine, and the phones are now  working.  Albeit, a temporary solution but one that has been working for a few weeks now.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: