This article explains how to configure an IPsec site with multiple active tunnels. For information about configuring IPsec with an Active/Passive configuration, see Configuring IPsec IKEv2 Sites
Note
Note: This is an Early Availability (EA) feature that is only available for limited release. For more information, contact your Cato Networks representative or send an email to ea@catonetworks.com.
Cato lets you configure multiple active tunnels for both the Primary and Secondary HA roles. Multiple active tunnels enable you to do the following:
-
Leverage Last Mile - With multiple active tunnels, you can distribute network traffic across different paths, helping to balance the load and improve network performance.
-
Redundancy - Multiple active tunnels provide redundancy. If one tunnel fails, traffic can be rerouted through another active tunnel, ensuring uninterrupted connectivity.
-
3rd-party integration - Integrate with 3rd-part SD-WAN CPEs for SSE services.
-
Traffic Segregation - Different tunnels can be used to segregate different types of traffic. For example, one tunnel could be used for voice traffic, while another could be used for data traffic.
You can configure up to 3 active tunnels for each HA role, which are connected to the same Cato PoP. Meaning, all Primary tunnels are connected to one PoP, and all Secondary tunnels are connected to a different PoP. Each tunnel must have a unique identifier, for example, a local ID such as FQDN or a public IP address.
After you create a new site that uses IPsec IKEv2 to connect to the Cato Cloud, edit the site and configure the IPsec settings.
Use the Connection Method settings to define if the Cato PoP only responds to connections from the remote site, fw init (Responder Only), or can also initiate connections (Bidirectional).
For sites that are working with dynamic IPs, the Cato Management Application generates a Local ID for the site, which is used for the Authentication Identifier that you select. Use the Authentication Identifier that is required by the third-party device: FQDN, email, or KEY_ID and enter the Local ID in the IKE settings of your third-party device.
In addition to the Local ID, configure a pre-shared key (PSK) for authentication.
You can choose to manage the downstream and upstream bandwidth for an IPsec site. If you want the Cato Cloud to cap your downstream bandwidth, enter the required limits accordingly. Otherwise, enter the values as defined by your ISP link's actual connection speed. If you don't know the ISP connection speed, configure the downstream bandwidth according to this site's license. For the upstream bandwidth, the Cato Cloud doesn't control the upstream traffic, and it isn't possible to cap it with a hard limit. Instead, the upstream bandwidth setting is a best-effort by the Cato Cloud.
Note
Note: If you enter upstream/downstream values that are greater than the actual connection speed of your ISP's link, the QoS engine is ineffective.
For more about QoS in Cato, see What are the Cato Bandwidth Management Profiles.
To configure the settings for an IPsec IKEv2 site:
-
From the navigation menu, click Network > Sites and select the site.
-
From the navigation menu, click Site Settings > IPsec.
-
Expand the General section and define how the site connects and authenticates to the PoP:
-
Select the Connection Mode for the site:
-
Responder Only – Firewall init. The site’s firewall initiates the connection and Cato responds
-
Bidirectional - The Cato PoP responds to negotiations for incoming connections and initiates outgoing negotiations.
-
-
Select the Authentication Identifier.
Bidirectional mode only supports IPv4 for the Authentication Identifier.
-
IPv4 - use the static IP address you configured in the Primary and Secondary sections for the site
IPv6 is currently not supported with IPSec over the Cato PoP.
-
FQDN, Email, KEY_ID - generates the Local ID in one of these formats
-
-
-
Expand the Primary section, and configure the following settings for the primary IPsec tunnel:
-
In Destination Type, select either FQDN or IPv4. The destination must be the same for all active tunnels for the HA role (Primary or Secondary).
-
FQDN - A Cato-generated hashed FQDN value is generated. This value is unique to the specific tunnel. This is the value you will provide to your firewall.
When selected, you must also define the PoP Location. Cato recommends you use Automatic so that the best PoP is selected for you. If you select a specific location and are also configuring a secondary site, make sure you select different locations.
-
IPv4 - select a static IP address from Cato IP (Egress) drop-down.
-
-
-
Click New. The Add Tunnel page appears.
-
Under Role, select which of the logical WAN interfaces to use for this tunnel. The WAN Role is used for priority-based routing in the Network Rules policy.
-
Under Name, enter a descriptive name
-
Under Public IP, enter the public IP address for this tunnel. Each tunnel must use a different public IP address
-
Private IPs is not relevant for multiple Active/Active tunnels. Leave these fields empty
-
In Last-mile Bandwidth, configure the maximum Downstream and Upstream bandwidth (Mbps) available to the site
-
In PSK, click Edit Password to enter the shared secret for the primary IPsec tunnel.
-
-
Click Apply. The tunnel is added to the primary table.
-
For sites that use a secondary IPsec tunnel, expand the Secondary section and configure the settings in the previous step and then click Save.
-
(Optional) Expand the Init Message Parameters section, and configure the settings.
As most IPsec IKEv2-supporting solutions implement automatic negotiation of the following Init and Auth parameters, we recommend that you set them to Automatic, unless specifically instructed to by your firewall vendor.
-
(Optional) Expand the Auth Parameters section, and configure the settings. See ??? for valid parameters.
-
Expand the Routing section, and define the routing options for the site:
-
For IPsec connections with a remote side that has SAs (Security Associations) defined for this tunnel, in the Network Ranges section, enter the local IP ranges for the SAs in this format <label:IP range> and click Add.
The remote IP ranges for the SAs are configured in the Site Configuration > Networks screen.
-
To enable the Cato Cloud to proactively attempt to re-establish a connection that is down, without waiting for the other side, select Initiate connection by Cato. Otherwise, the firewall attempts to re-establish the connection.
Note
Note: If no Network Ranges are configured for the site, it is considered as route-based VPN (implicit: 0.0.0.0 <> 0.0.0.0).
-
-
Click Save.
Wait at least 3 minutes before entering the primary and secondary FQDN values in your firewall to allow for the optimal PoP locations for these settings to be determined.
-
To show your connection details and status of the IPsec tunnel for this site, click Connection Status.
For more information about Init and Auth parameters, see this table.
By default, when all active tunnels of an HA role go down, Cato automatically reverts to the other HA role. Meaning, if all tunnels of the Primary HA role go down, HA is triggered, and Cato uses the Secondary tunnels as the next hop of all routes of the site. However, if the Primary HA role has 2 tunnels, and one tunnel remains up, a failover doesn't occur.
You can monitor tunnels through Link is down stories in the Stories Workbench.
Note
Note: It takes up to 30 seconds for Cato to determine that a tunnel went down.
By default, Cato is only able to control downstream traffic. Traffic is distributed across the tunnels (WAN links) based on health metrics, link preference, and the proportional ratio of the configured bandwidths for each link. The health metrics are re-calculated each second, and traffic is re-distributed to the best-performing link every 10 seconds.
Upstream traffic is controlled by the remote IPsec peer, and according to the policy-based routing the peer uses.
You can override the WAN link selection for downstream traffic using Network Rules. You can configure a rule to determine which WAN link is used for specific traffic tuples, in which case, traffic will be sent on the WAN link configured in the rule, and not the tunnel on which it arrived.
0 comments
Article is closed for comments.