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

ASA site to site VPN 1 HQ 30 branches

basel200952
Level 1
Level 1

Hello
i have a customer that asked me to connect 30 (ASA 5505)branches to HQ(ASA 5585-X) via VPN site-to-site i have created them and running very well
after that he wanted to make all branches network to see each other and I am new in ASA 
example i have site A (HQ) (all the tunnel connected here)
                        site B branch
                        site C branch

he want to make traffic from Site B to C and the opposite because we have IP telephony  in each branch
and we want to make call from branch to another

here is the running configuration from the HQ and 2 branches

any recommendations ?

2 Accepted Solutions

Accepted Solutions

First thing first these all appliances hardware are gone EOL (End of Life) and EOS (End of Support) and the software you running on these firewall are very old and have vulnerabilities on these be mindful of this fact.

what you has asked is not new you want your ASA in HQ site (A) to act as Hub whereas the branches need to act as spoke however the given senario of you to setup this up on ASA firewalls. Here is the link where similar setup in your given suitation is already implemented with configurations in order for you to provide the VOIP you might have to fine-tune and define the VOIP on the HQ, Branches

! QoS Configuration
class-map VoIP-Class
 match dscp ef

policy-map VoIP-Policy
 class VoIP-Class
  priority

service-policy VoIP-Policy interface outside

 

 

OR....

you can read this one.

Full mesh connectivity between your branch sites (B and C) through the HQ site (A), you'll need to ensure that the traffic can route through HQ to the other branches. This process involves configuring your ASA devices to allow traffic from one branch to another via the HQ ASA, essentially making HQ the transit point for inter-branch traffic.

I have not looked into your configuration therefore apologies for that but i can give you and run down with configuration to give you the complete picture.

Enable the command

same-security-traffic permit intra-interface

on the HQ ASA: This command allows the ASA to permit traffic to enter and exit the same interface, which is necessary for traffic from one VPN tunnel to be routed to another VPN tunnel.

You need to make sure the ACLs used in the VPN configurations at HQ allow traffic between the branch subnets. Specifically, the VPN ACLs should include the subnets for all branches.

access-list outside_cryptomap extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list outside_cryptomap extended permit ip 192.168.1.0 255.255.255.0 192.168.3.0 255.255.255.0
access-list outside_cryptomap extended permit ip 192.168.2.0 255.255.255.0 192.168.3.0 255.255.255.0

Ensure that your crypto map at HQ includes all branch subnets in the ACLs.

crypto map outside_map 1 match address outside_cryptomap

Ensure that traffic between branch subnets is exempt from NAT. On the HQ ASA, you should configure NAT exemption rules for all branch subnets.

nat (inside,outside) source static HQ_Subnet HQ_Subnet destination static BranchB_Subnet BranchB_Subnet no-proxy-arp
nat (inside,outside) source static HQ_Subnet HQ_Subnet destination static BranchC_Subnet BranchC_Subnet no-proxy-arp
nat (inside,outside) source static BranchB_Subnet BranchB_Subnet destination static BranchC_Subnet BranchC_Subnet no-proxy-arp

On Branch ASAs: Make sure the branch ASAs (B and C) have the necessary configurations to route traffic through the VPN tunnel to HQ for the other branch subnets.

Branch-B

access-list outside_cryptomap extended permit ip 192.168.2.0 255.255.255.0 192.168.3.0 255.255.255.0

Branch-C

access-list outside_cryptomap extended permit ip 192.168.3.0 255.255.255.0 192.168.2.0 255.255.255.0

Ensure their crypto maps and NAT configurations are updated similarly to reflect these changes.

 

 

please do not forget to rate.

View solution in original post

Yes, sure you can do that. Here is an artical for you with configurations.

crypto ikev2 enable outside 
crypto ikev1 enable outside

 

 

please do not forget to rate.

View solution in original post

5 Replies 5

ccieexpert
Level 1
Level 1

ASA does not have a way to create auto VPN like DMVPN, Flexvpn etc...for branch to branch traffic.

Not sure what is the latency through the hub.

If you want best performance, consider defining all 29 VPNs on each remote ASA - that gives you the best performance.

If you are ok for the traffic to go branch b <-->HQ<-->branch a, then you can create the remote subnet on each branch ASA to be a supernet like this for example: object-group network HQ_ASA
network-object 10.10.0.0 255.255.0.0

and same thing on the hub asa..

NAT exemption also have the same supernet.

On the hub you need this command for u-turn:

same-security-traffic permit intra-interface

Actually i would have preferred VTI and a routing protocol or just a supernet route and no need for NAT exemption as such.

https://www.packetswitch.co.uk/cisco-asa-route-based-vti-vpn-example/

 

Tom

Technoxi.com

CCIEx2 (Free initial consultation)

spoke to spoke connection must be pass through the Hub ?

MHM

First thing first these all appliances hardware are gone EOL (End of Life) and EOS (End of Support) and the software you running on these firewall are very old and have vulnerabilities on these be mindful of this fact.

what you has asked is not new you want your ASA in HQ site (A) to act as Hub whereas the branches need to act as spoke however the given senario of you to setup this up on ASA firewalls. Here is the link where similar setup in your given suitation is already implemented with configurations in order for you to provide the VOIP you might have to fine-tune and define the VOIP on the HQ, Branches

! QoS Configuration
class-map VoIP-Class
 match dscp ef

policy-map VoIP-Policy
 class VoIP-Class
  priority

service-policy VoIP-Policy interface outside

 

 

OR....

you can read this one.

Full mesh connectivity between your branch sites (B and C) through the HQ site (A), you'll need to ensure that the traffic can route through HQ to the other branches. This process involves configuring your ASA devices to allow traffic from one branch to another via the HQ ASA, essentially making HQ the transit point for inter-branch traffic.

I have not looked into your configuration therefore apologies for that but i can give you and run down with configuration to give you the complete picture.

Enable the command

same-security-traffic permit intra-interface

on the HQ ASA: This command allows the ASA to permit traffic to enter and exit the same interface, which is necessary for traffic from one VPN tunnel to be routed to another VPN tunnel.

You need to make sure the ACLs used in the VPN configurations at HQ allow traffic between the branch subnets. Specifically, the VPN ACLs should include the subnets for all branches.

access-list outside_cryptomap extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list outside_cryptomap extended permit ip 192.168.1.0 255.255.255.0 192.168.3.0 255.255.255.0
access-list outside_cryptomap extended permit ip 192.168.2.0 255.255.255.0 192.168.3.0 255.255.255.0

Ensure that your crypto map at HQ includes all branch subnets in the ACLs.

crypto map outside_map 1 match address outside_cryptomap

Ensure that traffic between branch subnets is exempt from NAT. On the HQ ASA, you should configure NAT exemption rules for all branch subnets.

nat (inside,outside) source static HQ_Subnet HQ_Subnet destination static BranchB_Subnet BranchB_Subnet no-proxy-arp
nat (inside,outside) source static HQ_Subnet HQ_Subnet destination static BranchC_Subnet BranchC_Subnet no-proxy-arp
nat (inside,outside) source static BranchB_Subnet BranchB_Subnet destination static BranchC_Subnet BranchC_Subnet no-proxy-arp

On Branch ASAs: Make sure the branch ASAs (B and C) have the necessary configurations to route traffic through the VPN tunnel to HQ for the other branch subnets.

Branch-B

access-list outside_cryptomap extended permit ip 192.168.2.0 255.255.255.0 192.168.3.0 255.255.255.0

Branch-C

access-list outside_cryptomap extended permit ip 192.168.3.0 255.255.255.0 192.168.2.0 255.255.255.0

Ensure their crypto maps and NAT configurations are updated similarly to reflect these changes.

 

 

please do not forget to rate.

can i enable both ikev1 and ikev2 in the same outside interface to start using VTI for other branches ?

Yes, sure you can do that. Here is an artical for you with configurations.

crypto ikev2 enable outside 
crypto ikev1 enable outside

 

 

please do not forget to rate.