Skip to main content

HA Unified WAN Management

Function Overview​

HA Unified WAN Management is used to manage WAN resources across two CPEs in an HA site, and to allow north-south NAT to select the local device WAN, Shared WAN, or Peer WAN as the egress based on service requirements.

In a traditional single-device egress scenario, SNAT usually selects only a local WAN or an address pool. In an HA site, WAN resources may be distributed across two CPEs. For example, WAN1, WAN2, WAN3, and WAN4 may all be used as north-south egresses. In this case, different internal subnets may need different SNAT addresses, address pools, and WAN egresses. When a specified egress is unavailable, routing, Route Track, or a fallback SNAT rule can determine whether traffic continues through another egress, falls back to the default route, or is no longer forwarded.

This feature applies to the following scenarios:

  • Two CPEs in an HA site both provide north-south Internet egress.
  • Different internal subnets need to use different SNAT addresses or address pools.
  • Multiple WAN egresses need to carry north-south traffic by priority or weight.
  • SNAT needs to select a Shared WAN, WAN (non-shared), or Peer WAN as the outbound interface.
  • DNAT needs to select Other VRF as the source and publish an internal service through a mapped address and port.
  • When the primary egress is abnormal, Route Track is required to switch traffic to a fallback rule or the peer device egress.

Key Concepts​

  • WAN (non-shared): A WAN that belongs to only one device. Address pools or NAT egresses bound to this WAN usually take effect only on the device that owns the WAN.
  • Shared WAN: A WAN managed jointly by the active and standby devices in an HA site. Basic configuration, transport network, QoS, and alerts are maintained in the Shared WAN configuration window.
  • IPv4 address pool: An IPv4 address resource that can be referenced by SNAT or DNAT. In an HA site, an IPv4 address pool can be bound to a WAN (non-shared) or a Shared WAN.
  • IPv4 IP:Port pool: A range of IP addresses and ports divided from an IPv4 address pool. It is commonly used by DNAT to publish internal services.

Configuration Entry Points​

Shared WAN Configuration​

"Tenant"→"Config"→"Sites"→"Edit Site"→"Global Configuration"→"WAN"→"Shared WAN" 🔗

Use the Shared WAN configuration window to maintain basic configuration, transport network, QoS, alerts, and other settings for Shared WAN.

Global Route Track​

"Tenant"→"Config"→"Sites"→"Edit Site"→"Global Configuration"→"WAN"→"Route Track" 🔗

Global Route Track checks connectivity to specified probe target addresses and can be referenced by configurations that require a global tracking result.

VRF Route Track​

"Tenant"→"Config"→"Sites"→"Edit Site"→"VRF Configuration"→"LAN"→"Route Track" 🔗

VRF Route Track can be referenced by SNAT rules in the same VRF to control whether the rule takes effect. When the Route Track status is abnormal, the SNAT rule that references it no longer matches, and traffic continues to match the fallback SNAT rule.

View Route Track Status​

"Tenant"→"Monitor"→"Sites"→"Site Detail"→"Network Object"→"Route Tracking" 🔗

In Network Object, you can view the current and historical status of Route Track. The page supports filtering Route Track entries by device, searching by probe name, and clicking the probe name to jump to the corresponding configuration.

If a Global Route Track is bound to a Shared WAN, it is displayed under both devices. If it is bound to a WAN (non-shared), it is displayed only under the corresponding device.

Route Track Status

Configuration Scenarios​

Scenario 1: Specify SNAT Egress by Source Subnet in a 4-WAN HA Site​

The customer site has two HA CPEs, and WAN resources are distributed across the two devices. For example, WAN1, WAN2, WAN3, and WAN4 may belong to different devices or serve different egress purposes. Different internal subnets need to access the Internet through different egresses and different SNAT addresses.

Configure the scenario as follows:

1. Plan WAN types

Confirm the type of each WAN in Global Configuration:

  • Keep a line used independently by a single device as WAN (non-shared).
  • Configure a same-type egress carried by both devices as Shared WAN.
  • When the local device needs to borrow the peer device egress, select the peer WAN through Peer WAN.

2. Configure address pools

Create IPv4 address pools in Address Pools and bind each pool according to address ownership:

  • Bind to Shared WAN when both HA devices use the same type of public address pool.
  • Bind to WAN (non-shared) when the address belongs only to one device egress.

3. Configure SNAT rules

Create SNAT rules in the NAT configuration of the VRF:

  • Source: Select the internal subnet or network object that needs a specified egress.
  • Destination: Usually select Internet.
  • Translation Mode: Select dynamic NAT, static NAT, or no translation based on requirements.
  • Translated Address: Select outbound interface or IP address pool.
  • WAN Egress: Select Shared WAN, WAN (non-shared), or Peer WAN.

If egress failure behavior needs to be controlled, plan routing priority, default route, Route Track, and fallback SNAT rules together. When the specified WAN is unavailable, whether traffic switches to another egress or stops forwarding depends on the combined NAT and routing configuration.

Scenario 2: Carry North-South Traffic by WAN Priority or Weight​

When an HA site has multiple WANs for Internet access, north-south routing priority can control the default outbound path. This configuration applies to the following scenarios:

  • Traffic should prefer a specified Shared WAN or WAN (non-shared), and use a backup WAN only when the primary egress is unavailable.
  • Multiple WAN egresses have similar capacity and should share traffic by weight.
  • The HA site has egresses on both the active and standby devices, and cross-device metric planning needs to avoid unexpected paths.

Configure the scenario as follows:

1. Configure Metric

Configure Metric for each WAN. A smaller Metric has higher priority. To configure primary and backup egresses, set a smaller Metric for the primary egress and a larger Metric for the backup egress.

Example:

  • shared-wan1: Metric 10, used as the preferred egress.
  • shared-wan2: Metric 20, used as the backup egress.

2. Configure Weight

When multiple WANs use the same Metric, Weight must be configured. Weight distributes traffic between WANs with the same priority. A larger Weight carries a larger share of traffic.

Example:

  • shared-wan1: Metric 10, Weight 70.
  • shared-wan2: Metric 10, Weight 30.

In this case, both WANs have the same priority, and traffic is distributed according to the configured weights.

note
  • Weight should not be configured when each Metric is unique.
  • Weight must be configured when multiple WANs have the same Metric.
  • For HA site Shared WAN, Metric planning between the active and standby devices does not support crossed priority configuration. If multiple Shared WANs use the same Metric, Weight must be configured.

Scenario 3: SNAT Selects Shared WAN, WAN (non-shared), or Peer WAN​

In an HA site, SNAT is no longer limited to the local device WAN. Different egress types can be selected according to service requirements.

Use Shared WAN as the egress

This applies when both HA devices jointly carry the same egress. After the Shared WAN configuration is saved, it takes effect for the HA site as a unified resource. SNAT rules that reference the Shared WAN work according to the current Shared WAN role.

Common configurations:

  • Set Translated Address to outbound interface, and select Shared WAN as the WAN egress.
  • Set Translated Address to IP address pool, and bind the address pool to Shared WAN.

Use WAN (non-shared) as the egress

This applies when a service subnet needs to egress from a specified WAN on a specified device. For example, the office subnet uses WAN1 on the active device, and the guest subnet uses WAN2 on the standby device.

Common configurations:

  • Set Translated Address to outbound interface, and select the corresponding WAN (non-shared).
  • Set Translated Address to IP address pool, and bind the address pool to the corresponding WAN (non-shared).

Use Peer WAN as the egress

This applies when traffic received by the local device needs to be forwarded over the HA link to the peer device WAN for Internet access. For example, the active device matches the service traffic, but the service should access the Internet through WAN2 on the standby device. In this case, select the corresponding Peer WAN in SNAT.

Peer WAN introduces cross-device forwarding. Before configuration, confirm that the HA heartbeat link and peer WAN status meet service requirements.

Use outbound interface address or no translation

SNAT rules can also provide lightweight egress control without using an address pool.

Translate to outbound interface address

This applies when you do not want to maintain a separate address pool and want to use the WAN outbound interface address directly as the source address. Set Translated Address to outbound interface and select the corresponding WAN egress.

No translation

This applies when you want to control traffic egress without changing the source address. The SNAT rule can still match source, destination, protocol, Internet Service, and other conditions, and select a specified WAN egress. The device keeps the original source address during forwarding.

note

No translation means no source address translation. It does not mean egress control is ignored. Actual forwarding is still determined by NAT rules, routing, and WAN status.

Scenario 4: SNAT Uses Route Track to Fail Over to Peer WAN​

When a service requires "primary egress first, peer egress after failure", Route Track can be used to control whether an SNAT rule takes effect.

Configure the scenario as follows:

1. Create a Route Track

Configure probe target addresses, source IP, source interface, interval, up count, and down count in VRF Route Track.

2. Configure the primary SNAT rule

Create the first SNAT rule, match the service traffic, select the primary egress, and reference the Route Track created in the previous step.

3. Configure the fallback SNAT rule

Create a fallback SNAT rule that matches the same type of service traffic and selects Peer WAN, Shared WAN, or another backup WAN as the egress.

When Route Track is normal, traffic matches the primary SNAT rule. When Route Track is abnormal, the primary SNAT rule no longer takes effect, and traffic continues to match the fallback SNAT rule and exits through the backup egress. After Route Track recovers, the primary SNAT rule can take effect again.

info
  • A Route Track that is referenced by SNAT cannot be deleted directly.
  • SNAT rules in a VRF can reference only Route Track entries in the same VRF.
  • Route Track controls only whether the rule that references it participates in matching. It does not automatically modify other SNAT rules.

Scenario 5: DNAT Uses Other VRF as Source to Publish an Internal Service​

When a service needs to be accessed by traffic from another VRF, DNAT can use Other VRF as the source and convert access traffic to the destination service address through a mapped address and port. This applies when only a specified service should be opened between VRFs instead of allowing full network reachability between the VRFs.

For example, an office VRF needs to access a DNS server, authentication server, bastion host, or application system in a service VRF. DNAT can provide a mapped address and port so that only this service is exposed.

Configure the scenario as follows:

1. Create an IPv4 address pool and IP:Port pool

Create an IPv4 address pool in Address Pools, and then create an IPv4 IP:Port pool based on that address pool. The IP:Port pool is used as the mapped address and port when another VRF accesses the service.

2. Configure DNAT rules

Configure the following items in NAT > DNAT Rules:

  • Source: Select Other VRF, and select the source VRF that is allowed to access the service.
  • Destination: Select the IP:Port pool.
  • Protocol/Port: Select the service protocol and port that need to be opened to the other VRF.
  • Translated Address/Port: Enter the target server address and service port in the service VRF.

3. Control the exposed scope

Select only the VRF that needs to access the service as the source, and configure the protocol and port according to the actual service. If multiple VRFs need to access different services, configure separate DNAT rules to avoid expanding the service exposure scope.

note

Selecting Other VRF as the source means publishing a specified service access entry through DNAT. It does not mean enabling full connectivity between the two VRFs.

Migration and Compatibility​

  • Non-HA sites can be migrated to the new Unified WAN Management interface.
  • If an HA site still has SNAT, DNAT, WAN Weight, address pool, or IP:Port pool configurations under the old model, it may not be migrated to the new model automatically. Related references need to be handled first.
  • Before migration, check NAT rules, address pools, IP:Port pools, and WAN references to avoid issues such as address pools not being deleted, WAN type not being switched, or NAT references being lost after migration.

Notes​

  • In Unified WAN Management scenarios, keep the concepts of WAN (non-shared), Shared WAN, Peer WAN, and active/standby WAN consistent.
  • IPv4 address pools can be bound to WAN (non-shared) or Shared WAN. IPv6 address pools can be bound only to WAN (non-shared), and do not support binding to Shared WAN.
  • A WAN (non-shared) that is referenced by an IPv6 address pool cannot be changed to Shared WAN.
  • Site-level shared address pools and exclusive address pools cannot use the same address.
  • If an address pool, IP:Port pool, WAN, VRF, or Route Track is referenced by SNAT or DNAT, deletion or modification is restricted by reference validation.
  • In north-south routing priority, Weight should not be configured when each Metric is unique. Weight must be configured when multiple WANs have the same Metric, and WAN entries cannot be missing.
  • Peer WAN egress uses a cross-device forwarding path over HA. Plan HA heartbeat link bandwidth, MTU, and capacity according to service traffic.