In this particular case, the ASAs are directly connected. The next hop is actually the other ASA. But even if there were other routers in between the two ASAs, the command would still be the same. Why? Because we are telling the local ASA specifically how to reach the subnet behind the remote ASA. It is assumed that the ASA, if connected to the internet, would already have a default route to the ISP router. However, we want this destination network to be sent directly to the outside interface of the remote ASA.
This might sound a little bit strange, configuring a static route with a destination IP address that is not directly connected. But this is acceptable. What will happen in this case is recursive routing.
If you have a router in bridge mode I assume you mean that it is passing traffic at layer 2, and not performing routing or any other layer 3 function. If this is the case, then there shouldn’t be any problems with such a setup. Just make sure that the outside interface of the ASA still has a routable (non-private) IP address and it is reachable from the other ASA. Also ensure that the router is passing through IPSec traffic (no filtering should take place).
These are just general guidelines based on the information you shared. There may be more parameters involved that may affect the operation of an IPSec VPN, so it all depends on the specifics of the setup. Let us know how you get along, and if we can be of further assistance.
Hello Rene/Laz,
How can I configure two IKEv2 IPsec Site to Site VPN tunnel on HQ-ASA-FW for the same destination encryption domain (10.0.0.0/24) so where one tunnel (to 2.2.2.2) will be acting as Active tunnel and another one (to 3.3.3.3) will be Standby tunnel?
Hmm, this is an interesting setup! It’s actually not too hard to do, the configuration is quite straightforward. The “trick” here is to use the same ACL for traffic selection for both crypto maps, so that both tunnels will select the same “interesting traffic.”
The other key is to configure SLA monitoring to track the primary tunnel for failover to the secondary tunnel.
Here are some key points that you should keep in mind:
Define two IKEv2 policies, proposals, keyrings, profiles as you would when creating two separate tunnels.
Define the IPSec transform set you will be using. You can define one for each of the tunnels, or a single transform set that will be referenced by both tunnels.
Define the IPSec profiles, one for each tunnel.
Define the ACL that will match interesting traffic. This ACL will be used by both tunnels.
Creat a crypto map that will configure both the primary and secondary tunnels under the same sequence.
Apply the crypto map on the outside interface.
Configure SLA monitoring for failover using an ICMP echo to monitor the status of the primary tunnel.
Finally, you can configure static routing with tracking, so that the SLA will affect which tunnel will be used to route traffic destined for the destination network.
Some lessons that will help you out in the above include:
Hello Laz,
For site to site IKEv2 route-based VPN tunnel, do I have to configure no-nat and bidirectional access-list to allow bidirectional traffic in addition to below configuration:
In a site-to-site IKEv2 route-based VPN tunnel, you do not necessarily need to configure NAT Exemption (i.e. no-NAT) or bidirectional access-list to allow bidirectional traffic. The traffic is allowed based on the routing table, not access-lists.
However, in some specific scenarios, you might need to configure NAT Exemption or use access-lists to control the traffic. For instance, if you have overlapping IP address spaces between the two sites, you would need to use NAT to translate the IP addresses. Similarly, if you want to restrict certain traffic over the VPN, you can use access-lists.
The configuration you have posted seems correct for establishing a basic IKEv2 route-based VPN tunnel. Just make sure that the networks you want to reach are correctly routed through the tunnel interface (using static routes or a routing protocol).
In addition, don’t forget to configure the necessary ACLs to allow the VPN traffic. The access-group commands you posted suggest that you have already configured these, but make sure that the rules allow the necessary VPN traffic.
