05-19-2024 12:59 PM - edited 05-19-2024 01:23 PM
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 ?
Solved! Go to Solution.
05-20-2024 02:18 PM
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.
06-02-2024 12:22 PM
Yes, sure you can do that. Here is an artical for you with configurations.
crypto ikev2 enable outside
crypto ikev1 enable outside
05-19-2024 10:24 PM - edited 05-19-2024 10:36 PM
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)
05-19-2024 11:37 PM
spoke to spoke connection must be pass through the Hub ?
MHM
05-20-2024 02:18 PM
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.
06-02-2024 05:56 AM
can i enable both ikev1 and ikev2 in the same outside interface to start using VTI for other branches ?
06-02-2024 12:22 PM
Yes, sure you can do that. Here is an artical for you with configurations.
crypto ikev2 enable outside
crypto ikev1 enable outside
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide