01-17-2014 10:18 AM
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?!
Solved! Go to Solution.
01-19-2014 05:35 AM
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
01-19-2014 05:35 AM
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
02-10-2014 07:18 PM
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.
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: