Network Tunnel Groups | Network Infrastructure | Cisco Secure Access Help

Network tunnel groups organize IPsec tunnels from supported network devices so traffic can connect securely to Secure Access through shared regional hubs. They provide redundant, highly available tunnel connectivity by pairing tunnels with primary and secondary data center hubs that can be monitored and managed as a group.

Tunnels and tunnel groups are core concepts in managing connections between your data centers and Cisco Secure Access. Supported network devices capable of establishing an IPsec tunnel can join a network tunnel group.

Secure Access enables fast, reliable, and secure private network connections to your applications through IPsec (Internet Protocol Security) IKEv2 (Internet Key Exchange, version 2) tunnels.
Network devices that are capable of establishing IPsec tunnels forward traffic to one of the Secure Access data centers where the tunnel head end is located.
User devices can read, write, and update private resources by setting up virtual private networks (VPNs) or zero trust access (ZTA) connections to Secure Access through these IPsec tunnels.
A network tunnel group provides the framework for establishing tunnel redundancy and high availability. Connect tunnels to the hubs within a network tunnel group to securely control user access to the internet and private resources.

Provisioning high-availability network tunnel groups at a hub site allows a group of tunnels to share a primary and secondary hub. Each data center hub in a network tunnel group can connect to multiple tunnels. A hub configured for NAT can support up to 100 tunnels. A hub that is not configured for NAT is limited to 10 tunnels.

Failover for Branch Connections in Secure Access Data Centers

For high availability, customer branch devices must connect to both the primary and secondary hubs in Cisco Secure Access data centers. They must have tunnel auto-reconnect enabled on the branch device and have a failure detection mechanism like Dead Peer Detection (DPD), IP SLA, or BGP timeout, depending on their use case. If you configure only a primary tunnel, you will experience interruption of service during regular maintenance windows or unplanned outages.

Under normal conditions, traffic flows through the primary data center. If the primary data center fails, traffic routes through the secondary data center. Switchover time depends on the nature of the primary tunnel failure and various timers.

Primary traffic failover to secondary can occur instantaneously if the Secure Access or customer branch device initiates and successfully terminates the IKE tunnel or BGP session.

Note

Terminating the IKE tunnel also terminates BGP.

In cases of communication failure between the branch device and Secure Access, traffic switches to the secondary only under the following conditions:

The Secure Access side DPD timeout occurs or the BGP hold timer expires.
The customer's DPD timeout is not effective in this situation because it does not result in tunnel termination on the Secure Access side.
The shorter of the Secure Access DPD timeout (156 seconds maximum; default and non-negotiable) and the BGP hold timer (90 seconds; default and negotiable) applies. For example, with a DPD timeout of 156 seconds and a BGP hold timer of 90 seconds, it takes at least 90 seconds for traffic to switch to the secondary tunnel.

Recommendations

Initiate a tunnel termination when a traffic failure is detected through the primary tunnel.
If initiating a tunnel termination is not feasible, terminate the BGP session or wait for the BGP hold timer to expire.
Configure the DPD timeout for your organization to match the Secure Access DPD timeout (156 seconds maximum). For example, 1 DPD every 30 seconds with 4 retransmits before failure: 30 seconds × 5 DPD = 150 seconds delay.

Add a Network Tunnel Group

This task describes how to configure network tunnel groups in Cisco Secure Access to provide high availability and redundancy for IPsec tunnels connected to data center hubs.

Network tunnel groups enable high-availability connectivity by allowing multiple IPsec tunnels to share primary and secondary hub sites. Any network device capable of establishing an IPsec tunnel can join a network tunnel group using the credentials generated during deployment.

Note

Hub capacity depends on your Network Address Translation (NAT) configuration:

With NAT: Supports up to 100 tunnels.

Without NAT: Limited to 10 tunnels.

Regardless of your network device type, the setup process follows these three steps:

Configure and deploy the tunnel group: In Secure Access, define the tunnel group attributes and deploy the group. Upon deployment, the tunnel group status changes from Unestablished to Inactive.
Configure tunnels on your network device: Configure the primary and secondary tunnels on your network device to send traffic to Secure Access. Associate these tunnels with the deployed tunnel group using the required attributes, including the tunnel ID, tunnel passphrase, and the Secure Access data center IP address.
Enable traffic flow and monitor status: Once user devices are configured to connect through the tunnel, Secure Access logs the traffic and the tunnel status changes to Active. You can monitor the status of tunnel groups and individual tunnels, as well as view related events, on the Secure Access Status page, Secure Access Overview, and Activity Search.

Follow these detailed steps to add a network tunnel group in Secure Access.

Before you begin

Ensure that your account has the Full Admin role in Secure Access. For more information, refer to Manage Accounts.

If you select a region and Secure Access returns with two data centers within that region, you can only swap the primary and secondary data center of a high-availability environment if the two data centers are Cisco owned data centers. You should only switch to your backup region if your primary region is unavailable.

Note

You cannot swap the primary and secondary data center if there is at least one AWS data center configured as a region.

Procedure

Navigate to Connect > Network Connections > Network Tunnel Groups.
Click Add.
Enter the General Settings for your tunnel group:
- Tunnel Group Name: Enter a meaningful name for the tunnel group.
- Region: Select a Secure Access region from the dropdown list. Click “+ Backup region” to add a backup primary and secondary data center for failover purposes. 
  
  Tip
  When you select a region, Secure Access displays two data centers within that region for you to choose from with one automatically assigned as the primary data center for you. You can swap the primary status of a region by clicking the “Make primary” button located under the secondary region. This is applicable to both the active HA region and the backup regions. 
- Device Type: Choose the network device type from the dropdown list.
- Click Next.

Enter the Tunnel ID.

Tunnel ID may be an email address or a primary and secondary pair of IP addresses.

Tunnel ID format requirements vary based on the device type selected in Step 1 - General Settings:


Device Type	Tunnel ID Format
Meraki MX	Email
Catalyst SDWAN	Email
ISR	Email
ASA	Email OR IP address (primary and secondary)
AWS	IP address (two each for primary and secondary)
AZURE	IP address (primary and secondary)
FTD	Email OR IP address (primary and secondary)
Other	Email OR IP address (primary and secondary)
VeloCloud	IP address (two each for primary and secondary)

Email tunnel ID requires the format <tunnel name>@<org><hub>.sse.cisco.com. Use the name you assigned to the tunnel group in Step 1 - General Settings.
IP address Tunnel IDs require both a primary and a secondary IP address.
IP address Tunnel IDs support both IPv4 and IPv6.

Enter a tunnel Passphrase between 16 and 64 characters in length. The passphrase must contain at least one upper case letter, one lower case letter, and one number. The passphrase cannot include any special characters. Backup regions, if configured, use the same passphrase.
Reenter your passphrase to confirm.
Click Next to continue.
Select Network Address Translation (NAT) if the IP address space behind this tunnel group overlaps with other IP address spaces in your network. NAT mapping translates real IP prefixes to unique mapped prefixes to resolve address conflicts and enable routing between branch sites, partner networks, and cloud applications. For more information, see NAT Mapping for Network Tunnel Groups.

Note
ECMP is not supported by tunnels with NAT mappings. For more information, see Equal-Cost-Multi-Path (ECMP) Support.

Note
For clients at this site to communicate with private resources at other sites, you must route return traffic to addresses in the 100.64.0.0/10 range through Secure Access.
1. Check the box to enable NAT and reveal the Source Mappings and Destination NAT Mappings sections.
2. Review the Source Mappings tiles.
  Source mapping tiles display the translation behavior for source IP addresses in each traffic direction.
  - Site → Secure Access — Source addresses are automatically translated to the Secure Access NAT subnet. This mapping is not configurable. To request a change to the source translation pool, contact Cisco Support.
  - Secure Access → Site — By default, source addresses are translated to the Secure Access NAT subnet. Override this default by enabling Translate to Secure Access NAT subnet and entering a custom IP prefix range. This mapping applies to all destination NAT mappings.
  Note
  When no destination mappings are configured, the Secure Access → Site source mapping has no effect. In this state, the NTG performs outbound-only NAT.
3. Configure Destination NAT Mappings.
  Destination NAT mappings translate destination IP addresses for traffic between your network and external destinations. You can create up to 100 mappings per direction in each NTG.
  
  Click + Add Mappings and configure the following fields:
  - Name — Enter a name that clearly identifies the mapping.
  - Direction:
    - Secure Access → Site — Translates destination IP addresses in the Original CIDR for inbound traffic to devices on your network. Sources send traffic to the Translated CIDR to reach destinations on your network.
    - Site → Secure Access — Translates destination IP addresses in the Original CIDR for outbound traffic from devices on your network. Devices send traffic to the Translated CIDR to reach cloud, branch, or partner destinations.
  - Original CIDR — The untranslated IP address range.
  - Translated CIDR — The translated IP address range.
  - Description — (Optional) Additional context for the mapping. Limited to 200 characters.
  - Summary — Displays a description of the translation in this format: Traffic destined to [Original CIDR] is translated to [Translated CIDR] in a 1-1 NAT translation.
4. Click the checkmark on the right side of the row to save the mapping.
- NAT mappings in the Site → Secure Access direction support overlapping mapped IP addresses between NTGs.
- NAT mappings in the Secure Access → Site direction do not support overlapping mapped IP addresses between NTGs. Each NTG must use unique mapped IP address ranges to avoid routing errors.
Note
When configuring private resources and access rules for NAT-mapped destinations, use the Translated CIDR for Secure Access → Site mappings and the Original CIDR for Site → Secure Access mappings. For more information, see NAT Mapping for Network Tunnel Groups.

Note
Enabling NAT disables the static and dynamic routing options for the NTG.
Internet Protocol Version Setting for Routing: Choose whether to Enable IPv6 Routing in addition to IPv4.
Choose a Routing option for this network tunnel group.
- Choose Static routing to manually add IPv4 and IPv6 address ranges for this tunnel group. You should add all public and private address ranges used internally by your organization. For more information, refer to Static Routing.
  
  Caution
  Adding a default route in static routing is not supported and can lead to traffic disruptions.
- Choose Dynamic routing when you have a BGP peer for your on-premise router. Enter the router's autonomous system (AS) number. For more information, refer to Dynamic Routing with BGP.
  - If IPv6 routing is enabled for Internet Protocol Version Setting for Routing, choose to enable IPv4, IPv6, or both internet protocol versions for peering. Then enter the router's AS number.
  - Expand Advanced Settings for additional dynamic routing options.
    - Multihop BGP — Enables BGP peers to establish a connection when not directly connected.
      
      Enter the IP Ranges from where BGP peering sessions will originate, then click Add
      
      (Optional) Enter the Hop count to limit the number of hops over which the BGP multihop session is established. The hop count equates to the time to live (TTL) parameter. The range is 1 to 254 hops, with a default value of 1. The hop count is disabled until IP addresses are entered. For more information, refer BGP Next-Hop Configuration.
    - Override BGP route summarization — By default, advertised routes are summarized using the configured summary subnets on the Route Summarization page. Select this option to override route summarization for this NTG. For details, refer to Manage Summary Subnets.
    - Multi-region backhaul supports a customer backhaul network that spans multiple Secure Access regions. Enable this setting for each network tunnel group connected to your backhaul. Overlapping prefixes advertised to multiple Secure Access regions from 1 NTG per region is supported when MRB is enabled. For more information, refer to Dynamic Routing with Multi-Region Backhaul.
      
      The Multi-Region Backhaul feature is currently controlled by a feature flag and is not available or enabled by default. To request access to this feature, please contact Cisco Secure Access Support.
      
      Note
      Inter-region high availability and MRB cannot be enabled simultaneously. If you opt to utilize inter-region high availability, you cannot configure MRB. The reverse logic applies so if you enable MRB, then inter-region HA is not available.
    - Block default route advertisement — Blocks the advertisement of the default route in dynamic routing mode. Advertising default routes via BGP is not supported and can lead to traffic disruptions.
Review and save network tunnel group information for use when setting up your network tunnel devices.
- Primary Tunnel ID: The ID you entered in Step 2 - Tunnel ID and Passphrase.
- Primary Data Center IP Address: The IPv4 and IPv6 addresses to which your network tunnel device will connect to establish the primary tunnel.
- Secondary Tunnel ID: The ID you entered in Step 2 - Tunnel ID and Passphrase.
- Secondary Data Center IP Address: The IPv4 and IPv6 addresses to which your network tunnel device will connect to establish the secondary tunnel.
- Passphrase: The passphrase you entered in Step 2 - Tunnel ID and Passphrase. This is the only time your passphrase is displayed.
Note
If you opted to configure backup regions, the primary and secondary data center and IP addresses in both the primary and secondary region are included in this page for review. Ensure the IPs and region designations are correct before you click Done.  
Click Download CSV to save your tunnel setup information. You can use the information to configure and deploy a tunnel in a network device.

Once the tunnel group is deployed, the initial state of the tunnel group changes from Unestablished to Inactive.

What to do next

After you configure the tunnel group, perform the following tasks to ensure a robust environment:

Configure primary and secondary tunnels: Configure your network devices to connect to both primary and secondary tunnels to ensure redundancy. For more information, refer to Configure Network Tunnels by Device,Tunnel throughput, capacity, and scaling, and Failover for Branch Connections in Secure Access Data Centers.
Enable user connectivity: Configure user computers to connect securely through the tunnel and send traffic to Secure Access.
Verify tunnel status: Once Secure Access receives traffic, the tunnel status changes to Active. Navigate to the Overview page to confirm the status of your configured tunnel.
Monitor traffic: Use the Overview page and Activity Search Report to monitor tunnel traffic events.
Configure alert rules: Set up automated alerts in the Secure Access dashboard or via email to receive notifications when tunnel groups enter a disconnected or warning state. For more information, refer to Monitor Secure Access with Alert Rules.

Delete a Network Tunnel Group

Once a network tunnel group is added to Cisco Secure Access, you can remove the deployed tunnel group from your organization.

Before you begin

Full Admin role in Secure Access. For more information, see Manage Accounts.

Procedure

Navigate to Connect > Network Connections > Network Tunnel Groups.
From the list of network tunnel groups, expand a tunnel.
Click the ellipsis (...), and then choose Delete.
After the delete is completed, verify that the tunnel group is not present in the list of network tunnel groups.

Edit a Network Tunnel Group

Once a network tunnel group is added to Cisco Secure Access, you can edit the configuration attributes of the deployed tunnel group.

When a network tunnel group is modified, the existing tunnel group is immediately terminated and a new one is established based on the new configuration, leading to a brief interruption in traffic flow while the re-negotiation process occurs. The exact duration of the disconnect depends on the complexity of the configuration change and the network conditions.

Before you begin

Full Admin role in Secure Access. For more information, see Manage Accounts.

Procedure

Navigate to Connect > Network Connections > Network Tunnel Groups.
From the list of network tunnel groups, expand a tunnel group.
Click the ellipsis (...), and then choose Edit.
Navigate through the settings to edit Tunnel Group Name, Region, Device Type, Tunnel ID, Passphrase, NAT Mapping, or Routing configuration attributes. This includes the settings for the primary and secondary backup regions if you configured those for your organization. Click “+ Backup region” to add a backup region. 

Tip

You can swap the primary and secondary data center of a region by clicking the “Make primary” button located under the secondary data center. 
Click Save.

View Network Tunnel Group Details

Once a network tunnel group is added to Cisco Secure Access, you can view the configuration attributes of a deployed tunnel group. You can also edit the attributes of a network tunnel group and view information about the network tunnels associated with the selected tunnel group.

Secure Access also lists the status of your network tunnels and information about the attributes of the deployed tunnel groups in Home > Connectivity.

Before you begin

A minimum role of Read Only in Secure Access. For more information, see Manage Accounts.

Procedure

Navigate to Connect > Network Connections > Network Tunnel Groups.
From the list of network tunnel groups, expand a tunnel group.
Click the ellipsis (...), and then choose View Details.
Review the Summary details for the selected network tunnel group. You can also view the Primary Hub and Secondary Hub details. If you opted to configure backup regions, the primary and secondary data center IPs are included in this page for review. If you want to swap the primary and secondary regions, you must edit the network tunnel group.  
Review the NAT Mappings table and edit entries in the table.

Note
NAT Mappings only apply to Network Tunnel Groups with Network Address Translation (NAT) enabled. For more information, refer to Add a Network Tunnel Group.
Click on a tunnel name under the Network Tunnels pane to view detailed information about the tunnel. You can also download a routing table for the tunnel.
(Optional) Click the pencil icon next to the network tunnel group name to edit the tunnel group attributes. See Edit a Network Tunnel Group

The connection status of network tunnel groups and hubs is determined by the following conditions:

Connected: Once Secure Access receives and logs traffic from a network tunnel, the tunnel status will switch to Active and the network tunnel group status will switch to Connected.
Disconnected: Both primary and secondary hubs are down and have no active network tunnels. This will result in a loss of connectivity for the network tunnel group.
Warning: One of the hubs of the network tunnel group is down and has no active tunnels. This will result in reduced failover and redundancy capabilities, and increased load on the remaining hub.

What to do next

Monitor tunnel traffic events in Secure Access Overview and Activity Search Report.
Configure rules to automate alerts in the Secure Access dashboard and by email when network tunnel groups are in a disconnected or warning state. For more information, see Monitor Secure Access with Alert Rules.

Manage Summary Subnets

Enable, disable, and override advertised BGP route summarization for network tunnel groups (NTGs) configured for dynamic routing with BGP peers. Summary subnets and summarization overrides apply globally across your Secure Access organization.

For more information, refer to Route Summarization.

Before you begin

You must have a Full Admin role in Secure Access. For more information, see Manage Accounts.

Procedure

Navigate to Connect > Network Connections > Network Tunnel Groups.
Click Route Summarization (top right).
In the Summary subnets table, click + Add.
Enter a comma-separated list of up to 100 subnet prefixes. Secure Access uses these prefixes to summarize advertised BGP routes.
Note
Note: The maximum number of summary subnets allowed is 100 in total. The Limit counter below the text field dynamically counts down from 100, reflecting the remaining number of summary subnets available. For example:
- If no summary subnets exist prior to opening the drawer, the counter displays Limit: 100 subnets.
- If 20 summary subnets have already been added, the counter displays Limit: 80 subnets.
- Each subnet in the Summary subnet field further decreases the count.
Click Add to save your changes.

The subnet prefix is added to the Summary subnet table. Secure Access automatically advertises the summary subnet in place of the more specific NTG egress routes it encompasses.

If a subnet prefix overlaps with an existing summary subnet, Secure Access displays the following error: Please enter a unique subnet that does not contain another subnet.

Override Route Summarization for a Network Tunnel Group

Override route summarization for specific network tunnel groups (NTGs) that need to receive individual, unsummarized routes. This is useful when large branches or data centers require the full set of advertised routes while smaller branches benefit from summarized routes.

You can configure this override from the Route Summarization page as described below. To configure an override from the NTG settings menu, refer to Add a Network Tunnel Group.

Before you begin

You must have a Full Admin role in Secure Access. For more information, see Manage Accounts.
Route summarization must be enabled with at least one summary subnet configured. For more information, see Manage Summary Subnets.

Procedure

Navigate to Connect > Network Connections > Network Tunnel Groups.
Click Route Summarization (top right).
In the Summarization Override table, click + Add.
Select up to 5 NTGs to override summarization.
Click Add to save your changes.

Note
You can add up to 5 NTGs at a time, but there is no limit to the total number of NTG overrides.

View Global Routes

The Global Routing table provides a centralized view of all routes that Secure Access uses to direct traffic between users and private resources across your organization's regions and networks. Use it to investigate overlapping routes, verify route priority, and confirm whether a route exists.

For more information, refer to Global Routing.

Procedure

In Secure Access, navigate to Connect > Traffic Management > Global Routing Table.

(Optional) In the search bar, enter a destination IP address or subnet.

All matching routes are displayed.

If your search returns no matching routes, Secure Access displays one of the following messages:


Message	Meaning
No available routes	The IP or subnet is a non-internet-routable address.
Internet bound route	The IP or subnet routes to the internet despite having no specific route.
Cannot reach internet	The IP or subnet cannot reach the internet until you add a backhaul.
No routes	No routes exist because you have not configured VPN, ZTNA, or NTGs.
Could not load routes	A system error is preventing routes from loading. Refresh the page and try again. If the problem persists, contact support. For contact information, see Welcome to Cisco Secure Access.
No routes found	Routes will appear once you begin advertising network subnets from this ingress region.

(Optional) Apply filters to narrow results:
- Egress region
- Connection type
- Ingress region (enabled only after you search for a subnet)
Review the results in the routing table.

The route marked Prioritized (blue label with a star) is the route Secure Access selects for the destination.
(Optional) Click Download CSV to export the results.
(Optional) To inspect a specific route, click the route's Subnet to open the detail drawer.
The information displayed in the detail drawer depends on the connection type.
General information (all connection types)
- Subnet (displayed at the top)
- Prioritized label (when search and Ingress region filter are applied)
- Connection type
- Egress region
Network details by connection type
- RAVPN and ZTNA
  - Data center — For RAVPN, the data center is based on your Secure Access configuration. For ZTNA, this can be any Cisco data center worldwide.
- NTG Static (NAT)
  - Framework: Network Tunnel Group
- NTG Static and NTG Dynamic
  - Framework: Network Tunnel Group
  - Connection name: NTG name (links to the NTG detail page)
  - NTG status: Connected, Disconnected, or Warning
  - Primary hub: Hub up or Hub down
  - Secondary hub: Hub up or Hub down
- NTG Dynamic with a backup region
  - Framework: Network Tunnel Group
  - Connection name: NTG name (links to the NTG detail page)
  - NTG status: Connected, Disconnected, or Warning
  - Main region (region name)
    - Primary hub: Hub up or Hub down
    - Secondary hub: Hub up or Hub down
  - Backup region (region name)
    - Primary hub: Hub up or Hub down
    - Secondary hub: Hub up or Hub down
- Site-to-Site VPN tunnel with Amazon Web Services
  For configuration details, refer to Configure a Site-to-Site VPN tunnel with Amazon Web Services.
  - Framework: Network Tunnel Group
  - Connection name: NTG name (links to the NTG detail page)
  - NTG status: Connected, Disconnected, or Warning
  - Primary tunnel hubs
    - Tunnel group 1: Hub up or Hub down
    - Tunnel group 2: Hub up or Hub down
  - Secondary tunnel hubs
    - Tunnel group 1: Hub up or Hub down
    - Tunnel group 2: Hub up or Hub down
Routing
- AS path

Establish an IPsec Tunnel

Prerequisites

Before you configure an IPsec tunnel to Secure Access, ensure the following items:

Your network device supports IPsec (Internet Protocol Security) IKEv2 (Internet Key Exchange, version 2) tunnels. Secure Access is compatible with any device that fully complies with the IKEv2 RFC standard.
Your network device firmware is up to date.
You have administrative access to the network device.
You have generated tunnel passphrase credentials in Secure Access.
The IP addresses of all endpoints within a network tunnel group, including the Secure Access hubs and the customer spoke endpoints, must be unique. However, if your endpoints are behind devices that apply NAT to the tunnel, you can reuse an IP address for your endpoints if you ensure that NAT translates unique source ports for each tunnel.

Note
Any third-party router or device that fully complies with the IKEv2 RFC standard should be able to connect to Secure Access. To confirm device compatibility, review the device documentation for IKEv2 RFC compliance.

Establish a Tunnel

You can establish an IPsec IKEv2 tunnel from a supported network device to a Secure Access data center. To configure the tunnel, use the tunnel passphrase credentials you generated in Secure Access.

For device-specific configuration steps, see Configure Network Tunnels by Device. The sample commands in those guides use the <secure_access_dc_ip> variable to represent the public IP address of the Secure Access data center you are connecting to.

For supported IPsec parameters, see Supported IPsec Parameters.

Maximum Transmission Unit (MTU) Size

IPsec tunnels for Secure Access must have an MTU of no larger than 1390 bytes for inner packets. Where possible, configure the MTU of the peer devices VTI interface to match 1390.
- Some devices (including Cisco FTD and Cisco Meraki) auto-calculate the VTI interface MTU by default and do not require manual configuration. Never reduce the MTU on physical interfaces (LAN or WAN).
Packets that exceed the MTU in the underlay or overlay are dropped. Exceeding the supported values risks fragmentation and packet loss.
If you experience fragmentation or packet loss, verify that your tunnel (inner) MTU does not exceed 1390 bytes and that TCP MSS clamping is correctly configured.

TCP MSS (Maximum Segment Size) Clamping

Cisco Secure Access automatically performs TCP MSS Clamping (1350 bytes) to ensure that TCP payloads are always small enough to be compatible with the maximum supported MTU. To avoid fragmentation and performance issues ensure that TCP MSS clamping is either disabled on the peer device, or configured to match the Secure Access supported value of 1350.

Path MTU Detection

Secure Access supports path MTU detection (PMTUD) to allow detection of the maximum packet size for other protocols (for example, UDP). Path MTU detection relies on ICMP packets; ensure ICMP Fragmentation Needed messages are allowed to cross from Secure Access to your local network.

Tunnel Throughput, Capacity, and Scaling

Each tunnel supports the following limits and allowances:


Parameter	Limit
Maximum throughput	1 Gbps per tunnel (in either direction)
Packets per second	No restriction
Users per tunnel	No restriction

Warning
Exceeding the 1 Gbps throughput limit may result in degraded performance, including increased latency and packet loss.

To achieve throughput beyond 1 Gbps, you can establish multiple tunnels. You can initiate multiple IPsec tunnels from the same device or aggregate tunnels from different devices within the same network tunnel group. When you use multiple tunnels, divide traffic with one of the following methods:

ECMP (Equal-Cost Multi-Path routing) — Load-balances traffic across tunnels. Secure Access supports up to 10 ECMP tunnels. For more information, see Equal-Cost Multi-Path (ECMP) Support.
Policy-based routing — Assigns specific traffic to specific tunnels based on your routing policies.

Secure Access also supports connecting multiple high-availability (HA) routers from the same branch in either Active - Active or Active - Standby mode. In an Active/Standby configuration, traffic routes through the primary tunnel when it is up. The secondary tunnel is used only when the primary tunnel is down; client routes are populated on the secondary tunnel only during failover.

To protect against loss of connectivity, set up redundant tunnels for a network tunnel group. For more information, see Manage Network Tunnel Groups.

Carrier-Grade NAT (CGNAT) Requirement

Secure Access internally uses the Carrier-Grade NAT (CGNAT) IP block for services such as ZTNA and Resource Connector. Proper handling of this IP space on your on-premises tunnel gateway is critical to prevent connectivity issues (such as the inability to access private resources, or inconsistent traffic routing), even when test connectivity results appear successful.

On your on-premises tunnel gateway, you must ensure the following:

Do not block traffic destined for the CGNAT IP address range (100.64.0.0/10).
Route all traffic destined for 100.64.0.0/10 through the tunnel to Secure Access.
Apply the same routing treatment to your customer-configured remote access VPN and system IP pool subnets. Ensure traffic destined for these subnets is routed through the tunnel to Secure Access and is not blocked.

Table 1. CGNAT routing requirements
Subnet or range	Required action
`100.64.0.0/10` (Secure Access CGNAT)	Do not block; route through the tunnel to Secure Access
Remote access VPN pool subnets (customer-configured)	Do not block; route through the tunnel to Secure Access
System IP pool subnets (customer-configured)	Do not block; route through the tunnel to Secure Access

The specific configuration steps vary depending on your device and environment.

For more information, see Add an IP Pool.

Client-Reachable Prefixes

By default, Secure Access routes all traffic destined for private RFC 1918 addresses back through the tunnel. This means Secure Access expects the source IP of outbound packets from your network to be a private RFC 1918 address.

If your network uses non-RFC 1918 source addresses, add those prefixes as client-reachable prefixes when you configure your tunnel. This overrides the default behavior so that Secure Access also routes return traffic for those prefixes through the tunnel. For information about address allocation and private networks, see RFC 1918.

Secure Access supports two options for client-reachable prefixes:

Static IP addresses — Must be globally unique within your Secure Access organization. No other network tunnel group in your organization can use the same address.
BGP-based dynamic routing — Enables advertisement of private network prefixes to physical network devices that support BGP (such as routers), removing the dependency on static route configuration.

After you update client-reachable prefixes for an established tunnel, wait at least five minutes, then disconnect and shut down the tunnel for at least ten seconds before reconnecting.

Supported IPsec Parameters

Cisco Secure Access uses the IPsec protocol for tunneling traffic. IPsec has multiple components and one of the core components is Internet Key Exchange (IKE). IKE manages negotiation with peers, authentication, and certificate exchanges. IKE maintains the session by using Dead Peer Detection (DPD) as per RFC 5996. Secure Access supports IKEv2, which is faster and more secure than IKEv1.

Secure Access supports the configuration of certain IPsec parameters to deploy a network tunnel. Even if a device can establish an IPsec tunnel to Secure Access, we do not guarantee that the tunnel is compatible. For example, if the tunnel enables Perfect Forward Secrecy (PFS), you can establish a tunnel, but in the event of reconnection, the tunnel may fail to rekey and lose service. We recommend that you test the tunnel connectivity thoroughly before putting any tunnel into production.


Components	IKEv2 (Phase I) (no IKEv1 support)	ESP (Phase II)
Encryption	AES-256-16 (GCM), AES-256-8 (GCM), AES-128-16 (GCM), AES-128-8 (GCM), AES-128(CBC), AES-256(CBC)	AES-256-16(GCM), AES-128-16(GCM), AES-256(CBC), AES-128(CBC), NULL(GCM) - AES-256 GMAC, NULL(GCM) - AES-192 GMAC, NULL(GCM) - AES-128 GMAC NULL(CBC)
Hashing	SHA256, SHA1	SHA256, SHA1
DH Group	20, 19, 15 14	20, 19, 15, 14
Authentication	Pre-Shared Key (PSK)	N/A
Protocol	N/A	ESP in UDP (NAT-T) (Port - UDP 4500)
Total Child SAs Supported	N/A	1
Lifetime (Rekey) Note Lifetime (Rekey) does not support seamless IKE re-authentication.	Based on client settings (IKE default is 4 hours)	Based on client settings (Child SA default is one hour)
Perfect Forward Secrecy (PFS)	N/A	Allowed (Ciphers configured with both PFS and non-PFS.) Note If the remote end prefers to negotiate PFS, it has to set the child rekey timer lower than the head end and/or allow both PFS and non-PFS. Reason: CNHE prefers non-PFS. We configured both, but if the other side wants PFS, we can negotiate.
DPD Timeouts*	1 DPD every 30 seconds 5 retransmits with exponential backoff (Maximum DPD timeout = 156 seconds)	N/A
IP fragmentation	Not supported	Not supported
IKE Fragmentation (RFC 7383)	Enabled	N/A
Extended Sequence Number (ESN)	N/A	Allowed and preferred

Recommendations are in Bold.

Note
Secure Access routing platforms are optimized for Galois/Counter Mode (GCM) encryption. Thus, we recommend that you use GCM encryption for maximum throughput. Using cipher block chaining (CBC) may result in lower throughput. Performance is subject to hardware and configurations.

* 1. DPD is sent 30 secs after the previous one (or tunnel up)

1st retransmit - after 2 secs
2nd retransmit - after 4 secs
3rd retransmit - after 8 secs
4th retransmit - after 16 secs
5th retransmit - after 32 secs
64 secs later, we give up - no more retransmits

Max total DPD timeout = 30 + 2 + 4 + 8 + 16 + 32 + 64 = 156 secs