Routing Options and Guidelines for Network Tunnel Groups

Overview

When your network and your partners' networks use overlapping IP address ranges, NAT mapping translates real IP prefixes to unique mapped prefixes. This resolves address conflicts and enables correct routing between branch sites, subnets, and cloud applications.

Secure Access supports explicit NAT mappings for both sources (such as endpoints that initiate requests) and destinations (such as internet destinations or private applications on your WAN). This enables bidirectional communication between sites and between sites and cloud resources.

Note

Secure Access does not support IPv6 for NAT mapping.

For NAT mapping configuration details, refer to the Routing option step in Add a Network Tunnel Group.

Key Capabilities

• Overlapping subnet resolution — Maps real IP prefixes to unique translated prefixes, resolving address conflicts and ensuring correct routing between branch sites and cloud applications.

• Bidirectional NAT flows — Supports both Secure Access-to-site and site-to-Secure Access traffic flows so that applications and users can communicate in both directions with correct address translations.

• Automatic route advertisement — Advertises static routes for mapped prefixes automatically to maintain network reachability after translation.

• Real-time validation — Validates mappings in the user interface to prevent overlapping or mismatched prefix lengths and avoid configuration errors.

• IP address conservation — Hides internal private IP addresses by translating them to public or unique mapped IPs, which conserves public IP address space.

NAT Terminology

You add network tunnel groups to Secure Access to enable secure network connections to the internet and private resources. When setting up a network tunnel group, you can choose static routing or dynamic routing (when you have a BGP peer for your on-premise router).

Use static routing for small, simple networks where predictable routes are needed and manual configuration is manageable. You might want to use static routes in the following cases:

• Your networks use an unsupported router discovery protocol.
• Your network is small and you can easily manage static routes.
• You do not want the traffic or CPU overhead associated with routing protocols.
• In some cases, a default route is not enough. The default gateway might not be able to reach the destination network, so you must also configure more specific static routes, such as a static route to an "inside network" when you need to explicitly direct traffic to a specific internal network segment that isn't reachable through the default gateway or via dynamic routing protocols.
• You are using a feature that does not support dynamic routing protocols.
• Note that advertising a default route using static routing is not supported and can lead to traffic disruptions.

Border Gateway Protocol (BGP) automates the exchange of routing information between autonomous systems (AS) to determine optimal paths for data traffic and failover routing without the need to configure and maintain static routes.

When setting up a network tunnel group in Secure Access, choose dynamic routing if you have a BGP peer for your on-premise router. Dynamic routing using BGP enables the advertisement of customer-specific routes, which is essential for Secure Access tunnels to properly route return traffic to your networks. Without these routes, return traffic cannot be routed correctly.

For more information about BGP, refer to Cisco Support documentation topics Select BGP Best Path Algorithm and Examine Border Gateway Protocol Case Studies

For Secure Access configuration details, refer to Add a Network Tunnel Group, View Network Tunnel Group Details, and Secure Access Regions.

Advantages of Dynamic Routing with BGP

• Automatic Route Updates—Route changes on the customer side are automatically communicated to Secure Access, eliminating the need for manual updates in the dashboard settings.

• Dynamic Failover—If a tunnel on the Secure Access side becomes unavailable, routes sent to the customer dynamically adjust, enabling seamless failover to a secondary tunnel.

BGP Peer Route Limitations

Exceeding the 10k routes per BGP peer limit resets the BGP connection and blocked further requests to use BGP on that network group tunnel. Review the following limitation for any specific environment limitations or recommendations:

• Each IPSEC/Meraki AutoVPN Network Tunnel Group is limited to a maximum of 10K routes per BGP peer.

Exceeding the route limitations resets the BGP connection and blocks further requests to use BGP on that network group tunnel.

Secure Access BGP Configuration Best Practices

Tunnel Redundancy and High Availability Principles

• A single network tunnel group can support multiple IPsec tunnels to achieve redundancy and high availability.

• For optimal redundancy, maintain a 1-to-1 correspondence between primary and secondary IPsec tunnels. For example, if you configure six primary IPsec tunnels to a data center for Equal-Cost Multi-Path (ECMP), you should have six corresponding secondary IPsec tunnels to ensure full redundancy. This setup requires one BGP connection per IPsec tunnel.

BGP Peer IP Addresses

• Secure Access (SSE) Side—Secure Access uses IP addresses within the 169.254.0.0/24 range for BGP peering. For example, the primary data center might use 169.254.0.5 and the secondary data center 169.254.0.9.

• Customer Side—For ease of configuration, it is recommended to use corresponding IP addresses within the 169.254.0.0/24 range (e.g., 169.254.0.6 for 169.254.0.5, and 169.254.0.10 for 169.254.0.9). However, the customer-side IP address range is not restricted to 169.254.0.0/24 and can be different.

BGP Identifier (Router ID)

• Do not use 169.254.0.1 as the BGP identifier.

• For the customer-side BGP identifier, use the local router's gateway address (typically an RFC1918 address, e.g., 192.168.x.x). Avoid using addresses within the 169.254.0.0/24 range. Note that some devices refer to the BGP identifier as the Router ID.

Customer Autonomous System Number (ASN)—Use any private BGP ASN within the range 64512–65534.

Note

eBGP peering can only happen between devices with different ASNs.

All newly created Secure Access organizations use the public ASN 32644 by default for BGP peering in network tunnel groups. Existing organizations established prior to November 2025 continue to use the private ASN 64512 that was previously reserved for Secure Access BGP peers.

If the private AS number 64512 is assigned to a device on your network, it will not be able to peer with a network tunnel group configured for Peer (Secure Access) BGP AS64512.

To identify the AS number used by your network tunnel groups, navigate to Connect > Network Connections > Network Tunnel Groups, click a network tunnel group by name, and check the field Peer (Secure Access) BGP AS to identify the ASN.

If your organization requires a different ASN, contact Cisco Secure Access support to request an update. For more details, refer Welcome to Cisco Secure Access. Note that changing the ASN is a global setting and will affect all network tunnel groups and BGP peering relationships for your Secure Access organization.

Route Advertisement by Secure Access—Secure Access advertises multiple routes for various services and components. To ensure the correct return path for traffic, separate routes are advertised for each region in use. The number of routes advertised will scale depending on the type of features deployed and the number of regions used by end users. The table below details the types of routes Secure Access advertises:

Routes advertised by Secure Access prepend the original AS path to include:

• 1 for primary tunnels

• 2 for secondary tunnels

This preserves the original AS path and allows customers to install all received routes in their Forwarding Information Base (FIB) and switch between primary and secondary routes based on their routing decisions.

Connecting Multiple High Availability (HA) Devices to Secure Access—Secure Access supports connecting multiple HA routers from the same branch, whether in Active/Active or Active/Standby mode.

• All IPsec tunnels from all HA routers must belong to the same Network Tunnel Group.

• Devices should advertise the same set of routes to Secure Access.

• Use AS path length to define device priority:

  • For Active/Active mode, use the same AS path length for all routes advertised by both devices.

  • For Active/Standby mode, advertise routes from your Active device with a shorter AS path length (e.g., length of 1 for Active, 2 for Standby).

• You can connect as many HA routers as needed, but a Network Tunnel Group is limited to a maximum of 20 IPsec tunnels overall (10 IPsec tunnels to the primary data center and 10 to the secondary).

• You can aggregate IPsec tunnels from different devices within the same network tunnel group if those devices are part of a HA pair (either Active/Active or Active/Standby mode).

• Do not aggregate multiple IPsec tunnels from different devices that are not part of an HA pair within the same network tunnel group.

Block Default Route Advertisement

Advertising default routes via BGP from the customer to Secure Access is not supported and can lead to traffic disruptions. You can block default route advertisements from Secure Access to the customer site.

1. From the Secure Access dashboard, go to Connect > Network Connections > Network Tunnel Groups.

2. In the Advanced Settings of the network tunnel group routing configuration, check Block default route advertisement.

Avoid Router ID and BGP Peer Conflicts

BGP requires a Router ID to establish BGP sessions between peers. Without a unique Router ID, BGP cannot establish peering sessions. When configuring Secure Access network tunnel groups, you can use the same BGP peer IP addresses for any or all of your network tunnel groups within the same region. However, the BGP Router ID must be unique to each BGP peer within a network. Each router in the network must have a unique Router ID.

Monitor BGP Client and Cloud Routes

To view BGP client routes received from your customer-side network:

• Navigate to Connect > Network Connections > Network Tunnel Groups.

• Click on a specific network tunnel to open its details pane on the right-hand side of the page.

• The Client Routes section displays the routes received from your network.

• Routes are visible on the primary tunnels. If multiple primary tunnels advertise the same route, the route will appear on each of those primary tunnels.

All other routes for your organization (those not originating from a primary tunnel) are displayed in the Cloud routes section of the network tunnel details pane.

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 Technical Support.

Secure Access network tunnel groups can extend customer backhaul networks across multiple Secure Access regions, providing enhanced routing and failover capabilities. With Multi-region backhaul (MRB), customers can connect their entire BGP fabric to Secure Access, allowing them to advertise the same routes in different Secure Access regions. With MRB, if active tunnels in a network tunnel group fail within a region and equivalent routes exist in other regions, Secure Access prioritizes routing traffic to standby tunnels in the same region before considering alternate regions.

Note

Overlapping prefixes advertised to Secure Access from multiple customer Network Tunnel Groups are supported by Secure Access BGP only when MRB is enabled on those Network Tunnel Groups. When MRB is not enabled, overlapping prefixes should not be advertised across multiple Network Tunnel Groups.

MRB requires the following conditions:

• The customer backhaul network must connect to two or more Secure Access network tunnel groups with Multi-region backhaul enabled.

• The customer backhaul network must use BGP to advertise subnet prefixes and preferences to Secure Access.

When MRB is enabled on network tunnel groups connected to the customer backhaul, Secure Access employs BGP attributes to prioritize traffic flow, particularly between primary and secondary tunnels:

• BGP community string: When a network tunnel group is created with MRB enabled, Secure Access advertises a BGP community string to the customer backhaul in the format 32644:X. In this string, 32644 is the Cisco Secure Access public Autonomous System Number (ASN), and X encodes regional priority. The customer backhaul network policy can then transform this BGP community string into an internal priority (e.g., a local preference for iBGP or an EIGRP metric) to preserve routing symmetry with Secure Access.

• Multi-Exit Discriminator (MED): If MRB is enabled, the primary Secure Access data center advertises the prefix with a MED value of 0, while the secondary data center uses MED: 1. The lower MED value is always preferred, ensuring that the primary data center is preferred for routing whenever possible.

For more information, see the Cisco SASE Design Guide Deep Dive.

When MRB is not enabled, Secure Access typically uses the AS path length for route prioritization between primary and secondary tunnels instead of MED. BGP prefers shorter AS paths.

Multi-Region Backhaul Scenarios

Multi-region backhaul supports the following scenarios:

• Local Tunnel Failover—When a primary tunnel fails, the network tunnel group automatically fails over to the secondary tunnel within the same region.

• Regional Failover—If an entire Secure Access region fails, traffic fails over to another region connected to the customer backhaul. To enable regional failover, Multi-region backhaul must be enabled on all relevant network tunnel groups connected to the customer backhaul network.

• RAVPN User Access to Remote Resources—If an RAVPN user connects to a Secure Access region that is not directly connected to the customer backhaul where the requested private resource resides, Secure Access forwards the RAVPN user traffic to the appropriate region to complete the request.

• Optimal RAVPN Return Traffic—Secure Access advertises RAVPN user route prefixes and preferences to the customer backhaul. This ensures optimal routing of return traffic and helps avoid asymmetric routing by customer routers.

This diagram illustrates a private resource within a customer backhaul network spanning Secure Access Regions A and B. Region C is not directly connected to the backhaul. All three regions share routing information. The customer backhaul can advertise the same prefixes in all the Secure Access regions without breaking traffic symmetry. Secure Access always uses the shortest path to the backhaul.

The customer IPsec router is connected to a network tunnel group in Secure Access Region A, which is the customer's preferred route to the subnet prefix advertised by BGP (10.0.0.1/32 in this example).

Scenario A: Local Tunnel Failover

When the primary tunnel fails, the network tunnel group fails over to the secondary tunnel within the same region. Automatic failover from the primary to the secondary tunnel is the expected behavior with or without Multi-region backhaul enabled.

When Multi-region backhaul is not enabled on the network tunnel group, the subnet prefix will only be advertised for that network tunnel group, and remote users will only be able to access the private resource from Region A.

Scenario B: Regional Failover

When Multi-region backhaul is enabled, the subnet prefix will be advertised to multiple network tunnel groups that may span Secure Access regions. Each region will prioritize local routes.

• Region B learns the prefix and routes advertised for both Region A and Region B, and prioritizes local routes.

• User B connects to RAVPN via DC B1 in Region B and accesses the private resource via the primary tunnel in Region B.

• If the network tunnel group between Region B and the customer backhaul goes down, automatic failover supports User B's access to the private resources via the primary tunnel in Region A.

Scenario C: Access from an Unconnected Region

• In this scenario, the customer has not set up a network tunnel group in Region C. Without a direct connection to the customer backhaul, Region C learns the prefix and routes advertised for both Region A and Region B.

• Region C prefers Region B because it is closer.

• As in Scenario B, if Region B goes down, automatic failover supports User C's access to the private resource via the network tunnel group in Region A.

For configuration details, refer to Add a Network Tunnel Group, View Network Tunnel Group Details, and Secure Access Regions.

This topic describes how BGP next-hop addresses are configured for customer route advertisements based on the BGP session type and neighbor addresses. For more information, see Dynamic Routing with BGP and Add a Network Tunnel Group.

Session Types and Next-Hop Behavior

1. Dual-Stack BGP Sessions (IPv4 and IPv6)—Each address family uses its corresponding BGP neighbor address as the next-hop.
   • IPv4 routes: Next-hop matches the IPv4 BGP neighbor address.
   • IPv6 routes: Next-hop matches the IPv6 BGP neighbor address.
2. IPv4-Only BGP Session—Can advertise both IPv4 and IPv6 prefixes.
   • IPv4 routes: Next-hop matches the IPv4 BGP neighbor address.
   • IPv6 routes: Next-hop is derived by mapping the IPv4 neighbor's suffix to the IPv6 prefix.
3. IPv6-Only BGP Session—Can advertise both IPv4 and IPv6 prefixes.
   • IPv4 routes: Next-hop is derived by mapping the IPv6 neighbor's suffix to the IPv4 prefix.
   • IPv6 routes: Next-hop matches the IPv6 BGP neighbor address.

Example BGP Next-Hop Configuration

This example shows how to configure route advertisements given these prefix ranges:

• IPv4: 169.254.0.0/24
• IPv6: 2a04:e4c4:b:c723::b67:0000/120

Scenario 1: IPv6 BGP session—If your BGP peer address is 2a04:e4c4:b:c723::b67:0009, Secure Access dynamically sets the next-hop addresses based on the peer:

• IPv4 next-hop will include the mapped suffix 0x9: 169.254.0.9
• IPv6 next-hop will match the peer address: 2a04:e4c4:b:c723::b67:0009

Scenario 2: Dual-stack IPv4/IPv6 BGP session—If your BGP peer addresses are 169.254.0.5 and 2a04:e4c4:b:c723::b67:0009, Secure Access sets the next-hop addresses to match the peer:

• IPv4: 169.254.0.5
• IPv6: 2a04:e4c4:b:c723::b67:0009

Next-hop addresses always match the BGP neighbor address for the corresponding address family when both IPv4 and IPv6 sessions are established.

Secure Access BGP will not advertise a prefix larger than /22. When you configure a user VPN pool for remote access VPN (RAVPN) in Secure Access, the platform processes the network as follows.

Prefix larger than /22

If the provided network is larger than /22 (e.g., /20), the platform automatically splits the network internally into multiple /22 chunks.

Example:

• You provide a /20 pool.

• Secure Access splits this into 4 × /22 subnets internally.

• Each /22 is leased by a data center in the region on demand.

• When a data center leases a /22, it advertises only that /22 (or smaller) over BGP — not the full /20.

Prefix equal to /22 or smaller

If the provided network is /22 or smaller (e.g., /24), the platform splits the network into at least two smaller subnets to support high availability across a minimum of two data centers in the region.

Example:

• You provide a /24 pool.

• Secure Access splits this into 2 × /25 subnets.

• Each /25 is assigned to a different datacenter in the region.

• Each data center advertises its respective /25 over BGP.

VPN pool subnet advertisement scaling on demand

VPN pool subnets are not all advertised simultaneously. Instead, they are allocated and advertised on demand as the number of RAVPN client connections increases: Initially, only the first subnet (e.g., the first /22 of a /20) is leased and advertised via BGP. As demand grows, additional subnets are leased by data centers and subsequently advertised. This is consistent with how cloud resources are dynamically scaled.

Example:

• You configure 4 × /22 pools to cover a /20 range.

• At low connection volume, BGP advertises only the first /22.

• As RAVPN connections increase, the remaining /22 pools are activated and advertised incrementally.

If you observe that only one of your configured pools is being advertised, this is expected behavior. Additional pools will be advertised as scaling demands require.

Key takeaways

• Maximum BGP advertised prefix: /22 — Secure Access never advertises a network larger than /22 over BGP.

• Automatic splitting — Networks are split internally for high availability (minimum 2 data centers per region) and scalability.

• On-demand advertisement — Subnets are advertised via BGP only when they are actively leased by a data center to serve connections. Not all pools appear in BGP at once.

• Scaling is dynamic — Additional pool subnets are activated as RAVPN client connection counts increase, following cloud-native resource scaling principles.

Equal-Cost-Multi-Path (ECMP) is a routing strategy that distributes next-hop packet forwarding across multiple tunnels with equal routing cost. In Cisco Secure Access, ECMP load-balances traffic across primary IPsec tunnels within a Network Tunnel Group (NTG), improving bandwidth utilization and providing redundancy. If primary tunnels become unavailable, traffic failover to secondary tunnels is automatic and ECMP will continue to route traffic across equal cost paths.

Key capabilities

ECMP behavior

Understanding how ECMP handles traffic flows is critical for proper deployment. When a network tunnel group has multiple IPsec tunnels to the same data center, Secure Access automatically applies ECMP in the following conditions:

• Static routing — ECMP occurs automatically across all IPsec tunnels in the NTG. For more information, refer to Static Routing.
• Dynamic routing — ECMP occurs automatically across all IPsec tunnels where the same prefix is advertised on BGP connections. For more information, see Dynamic Routing with BGP.

ECMP is supported on tunnels within a single NTG but is not supported on tunnels between NTGs. If multiple prefixes need to be advertised over different NTGs in different regions, consider enabling Multi-Region Backhaul on the NTGs. For information about how Multi-Region Backhaul works in Secure Access, refer to Dynamic Routing with Multi-Region Backhaul. For information about configuring Multi-Region Backhaul, refer to Add a Network Tunnel Group.

Default behavior: stateless ECMP

By default, ECMP operates in stateless mode:

• A hash of packet fields ensures all packets from a single flow follow the same path.
• Flow stickiness is not enforced, meaning forward and return paths may differ: A flow may traverse Tunnel 1, while return traffic comes back through Tunnel 2.

Example: A user initiates a connection that is routed through Tunnel 1. The response from the destination may return through Tunnel 2 if both tunnels are part of the same ECMP group.

Note

Secure Access ECMP hashing uses source IP, destination IP, protocol, and IPv6 flowlabel, deliberately excluding ports. This design ensures that IP fragments or related flows without port information follow the same ECMP path, leveraging the IPv6 flowlabel to maintain flow consistency in IPv6 environments. By contrast, default ECMP hashing uses the 5-tuple: source IP, destination IP, source port, destination port, and protocol.

Stateful ECMP with NAT for Secure Internet Access (SIA)

When an NTG is configured to use outbound NAT for an SIA tunnel use case, ECMP behavior is stateful: Outbound NAT enforces flow stickiness, so both forward and return traffic use the same tunnel.

Use case: Enable NAT when internet destinations require symmetric routing or when firewalls/security devices need to see both directions of a flow on the same path.

Note

• Unless stateful ECMP is required for a specific use case, it is not best practice to use ECMP with an NTG that is configured to use NAT. NAT may reduce routing performance and reliability.
• NTGs configured to use NAT do not support ECMP for a Secure Private Access (SPA) tunnel use case.

For more information, see Network Address Translation (NAT) on Add a Network Tunnel Group.

Configuring ECMP

To enable ECMP, each tunnel must be uniquely identifiable using one of these methods:

• Different public IP addresses, OR
• Unique tunnel name prefixes (+1, +2, +3, etc.)

Additional ECMP requirement: For ECMP to distribute traffic across multiple tunnels to the same remote peer, each tunnel must use a unique combination of source IP address and UDP source port. ECMP commonly hashes on the outer packet headers. If multiple tunnels use the same effective source IP address and UDP source port, they can hash to the same path, reducing or eliminating the benefit of load balancing.

You can meet this requirement in either of these ways:

• Use a different public source IP address for each tunnel.
• Use a different local source address for each tunnel, such as a dedicated loopback interface per tunnel. If all tunnels share the same public WAN IP address, use NAT/PAT to assign a unique translated UDP source port to each tunnel.

A common approach is to use one loopback interface per tunnel:

1. Create a separate loopback interface for each tunnel and assign each loopback a unique IP address.
2. Configure each tunnel or IKE/IPsec peer to use its assigned loopback as the local source address.
3. If all tunnels egress through a single public WAN IP address, configure NAT/PAT so that each loopback-sourced tunnel is translated to the same public IP address with a unique UDP source port.
4. Verify that each tunnel presents a unique source IP address and UDP source port combination on the WAN.

Note

When NAT is used, uniqueness is determined by the translated outer source IP address and UDP source port seen on the WAN, not by the internal loopback address alone.

Note

The requirement applies to the source IP address and source UDP port used on egress. The destination UDP ports used for IKE or NAT remain unchanged.

Caution

Do not configure multiple tunnels with the same effective source IP address and UDP source port. If you do, those tunnels can follow the same ECMP path, which can prevent traffic from being balanced across available paths.

Tunnel naming convention

When creating multiple tunnels to the same hub within an NTG, use the following naming convention:

Note

• The prefix values (+1, +2, etc.) must be sequential. Maximum of 10 tunnels per hub.
• Although you add prefixes (+1, +2, etc.) to differentiate tunnels, Secure Access strips these identifiers during authentication to keep the tunnels grouped under the same NTG.

Step-by-step: Enabling ECMP

1. Plan your tunnel architecture. Determine the number of tunnels needed based on throughput requirements. Plan an equal number of tunnels for Primary and Secondary DCs for failover parity.
2. Configure tunnel names with prefixes. For each additional tunnel to the same hub:
   1. Use the base tunnel name for the first tunnel, for example SDWANCSS@<domain>.
   2. For each additional tunnel to the same hub, append a numeric suffix:
      1. Second tunnel: +1
      2. Third tunnel: +2
      3. Continue up to +9 (for a maximum of 10 tunnels)
3. Ensure that each tunnel is differentiated for ECMP. Each tunnel must present a unique combination of source IP address and UDP source port on egress. You can achieve this by using one or both of the following:
   1. A unique public source IP address for each tunnel
   2. A unique UDP source port for each tunnel, configured manually or through NAT/PAT on egress
4. Configure NAT based on the deployment design.
   1. If the NTG performs source NAT for tunnel-bound traffic, enable Outbound NAT on the NTG.
   2. If the attached device is a firewall, do not enable Outbound NAT on the NTG.
5. Enable ECMP on the device that forwards traffic across the tunnels.
   1. If the attached device is a firewall, enable ECMP on the firewall.
   2. Configure the device to preserve flow symmetry so that return traffic uses the same tunnel as forward traffic.
6. Validate the configuration.
   1. Verify that each tunnel uses a unique effective source IP address and UDP source port on the WAN.
   2. Verify that traffic is distributed across the expected ECMP paths.
   3. If stateful inspection is used, verify that return traffic follows the same tunnel as the forward traffic.

Best practices