Space private WAN¶
For more information on private WAN (PWAN), please refer to the private WAN documentation. This document describes details of how to configure private WAN options for a space.
The Private WAN tab of the space page lists the PWAN configuration options for the space. These options apply only to the individual space, not to any descendant spaces. Though spaces are hierarchical for organization and access control in the management application, spaces are not hierarchical with regards to PWAN. Instead, each PWAN space is completely isolated from other spaces, even if they have a parent-child relationship in the management application. If bonds are to communicate with each other using PWAN features, they must be assigned to the same space.
To enable or disable private WAN for a space, toggle the “Enable private WAN” option and select the desired mode of private WAN, and then click “Save”.
Different modes operate very differently. Managed mesh is the recommended mode, but you should research each mode and decide which is best for your needs. Refer to the private WAN documentation for details.
Managed mesh¶
Main article: PWAN Managed mesh
Managed mesh PWAN configures VXLAN and Wireguard encrypted tunnels between all aggregators.
Routing to external networks requires custom protocol configuration to be defined on at least one aggregator.
Include aggregator interfaces assigned to this space in the mesh¶
By default, the managed mesh only includes the VXLAN interfaces for routing private WAN traffic between aggregators. While custom routing protocols can be used to add more direct routing via physical, VLAN, and custom VXLAN interfaces, certain information about the routes, in particular the distance cost, may be lost. This may result in poor routing decisions, especially when OSPF is used.
If the “Include aggregator interfaces in managed mesh” option is enabled on the space, any interfaces defined on the aggregator directly or via a routing group VLAN association will be added to the mesh with a lower cost than the automatic managed mesh VXLAN interfaces. This allows for more efficient routing in most scenarios.
The preference of routes will be determined based on the full distance cost of all the hops to the destination, where the cost of each hop type is ordered as follows, least-to-most:
Any defined physical, VLAN, or VXLAN interfaces on the aggregator
The automatic managed mesh VXLAN interface shared with aggregators in the same routing group
The automatic managed mesh VXLAN interface shared with aggregators in other routing groups
Unmanaged¶
Main article: PWAN unmanaged
Unmanaged PWAN requires custom protocols to be configured on every involved node to manage how traffic is routed between those nodes and external networks.
There are no other space options for this mode.
With private WAN routers¶
Warning
Private WAN routers will be deprecated in SD-WAN on August 1, 2025. Please see Migrating to managed mesh for information on migrating an existing deployment using private WAN routers to a managed mesh.
Main article: PWAN with private WAN routers
With private WAN routers PWAN uses the gateways and rules configured on the space to route PWAN traffic via private WAN routers.
When private WAN is enabled in ‘with private WAN routers’ mode, traffic from bonds in the space is not routed from an aggregator to a partner’s core router; instead, it is routed either directly to other bonds in the same space on the same aggregator, or routed via a PWAN router to bonds in the same space on different aggregators.
Before enabling private WAN on a space, ensure there is a PWAN router at each routing group where bonds in the space are active. For example, if a PWAN space has bonds running on aggregators in Vancouver and New York routing groups, but no bonds on aggregators at a Dallas routing group, then PWAN routers must be deployed at the Vancouver and New York routing groups before PWAN will work. If no PWAN router is available at a routing group where PWAN bonds are running, the bonds will route traffic as if PWAN was not enabled on their space.
Centralized Internet access¶
Enabling PWAN allows bonds to communicate privately, but does not allow them to route traffic to the Internet. To use centralized Internet access, at least one gateway must be configured.
If inbound Internet traffic is to be accepted directly via a PWAN router, inbound rules must be configured. For a description of the different types of gateways when using With private WAN routers and the purpose of 1:1 NAT and port forward rules, please see Private WAN gateways.
Gateways for private WAN routers¶
There are three different types of gateways for private WAN routers, as described in Private WAN gateways. Each routing group available to the space can have one gateway, and different routing groups can have different types of gateways.
The options available for each type of gateway are as follows:
NAT via PWAN router¶
Enabled¶
When checked, applies the rules on the PWAN router.
IP¶
The public IPv4 address to use for outbound traffic. This IP must be allocated to the space.
Routing groups¶
The routing group where the gateway should be applied. The allocation which holds the public IP address must be valid at each of the selected routing groups.
Note¶
A free-form field for any relevant information.
Example¶
In the following example setup, traffic bound for the Internet arriving at a PWAN router in the Granville Networks-Vancouver routing group would be NAT’ed to 198.51.100.34.
Dedicated gateway via PWAN router¶
Enabled¶
When checked, applies the rules on the PWAN router.
IP¶
The IPv4 address, with CIDR netmask, to assign to the given VLAN interface on the PWAN router. Since this is usually a private IPv4 address, it does not need to be allocated to the space.
Gateway¶
The IPv4 address of the dedicated gateway for this space. It must be within the subnet of the IP field.
IPv6¶
The IPv6 address, with CIDR netmask, to assign to the given VLAN interface on the PWAN router. IPv6 addresses are not managed with allocations.
IPv6 gateway¶
The IPv6 address of the dedicated gateway for this space. It must be within the subnet of the IPv6 field, unless it is a link-local address.
VLAN¶
The VLAN used to communicate with the dedicated gateway. This VLAN is applied to the interface specified in the PWAN router’s VLAN trunk interface field.
Routing groups¶
The routing group where the gateway should be applied.
Note¶
A free-form field for any relevant information.
Example¶
In the following example setup, IPv4 traffic bound for the Internet arriving at a PWAN router in the Granville Networks-Vancouver routing group is forwarded, without NAT, to the gateway at 10.133.2.2 on VLAN 23. The gateway must have its own routes forwarding all connected IP and routed IPv4 networks back to the PWAN router at 10.133.2.1. For example, if a bond in the PWAN has a connected IP 10.1.0.1/24 and a route 10.2.0.0/24, the gateway must have routes 10.1.0.0/24 via 10.133.2.1 and 10.2.0.0/24 via 10.133.2.1.
Likewise, IPv6 traffic destined for the internet arriving at a PWAN router in the Granville Networks-Vancouver routing group is forwarded to the link-local gateway at fe80:1::/128 on VLAN 23. The gateway must have its own routes forwarding all connected IP and routed IPv6 networks back to the PWAN router at 2001:DB8::, analogous to an IPv4 setup.
Dedicated gateway via bonder¶
Note
With the addition of managed mesh, it is suggested to simply add a route of 0.0.0.0/0 on bonders instead. This will allow a setup that can be used with both managed mesh and private wan routers.
Enabled¶
When checked, applies the rules on the PWAN router.
Gateway¶
The IPv4 address of the dedicated gateway for this space. It must be within the subnet of a connected IP or route on a bond in the space.
IPv6 Gateway¶
The IPv6 address of the dedicated gateway for this space. It must be within the subnet of a connected IP or route on a bond in the space.
Routing groups¶
The routing group where the gateway should be applied.
Note¶
A free-form field for any relevant information.
Example¶
In the following example setup, IPv4 traffic bound for the Internet arriving at a PWAN router in the Granville Networks-Vancouver routing group is forwarded, without NAT, to the gateway at 192.168.1.2 via the 10.0.0.2 route. Similarly, IPv6 traffic is forwarded to the gateway at 2001:db8::2.
Here is an example of a configuration of connected IPs and routes on a bond to support this gateway configuration.
With this configuration, traffic is routed from PWAN routers and aggregators to the above bond since it has a route for 192.168.1.2 via 10.0.0.2. The bonder then routes that traffic to the gateway at 192.168.1.2, and hairpins traffic for connected IPs and routes on other bonds in the space back through the bonding tunnel.
In this example, the gateway could use the IP 198.51.100.74 to send traffic back to the bonder at 198.51.100.73, which would route that traffic up to its aggregator and then to the Internet. Another use-case is to route traffic from the gateway to another internet access point. In this example, the gateway at 2001:db8::2 could forward traffic to an alternative source of internet (e.g. a fibre pipeline). This, of course, requires configuring routes back to the bonder on the access point.
NAT¶
A limited amount of NAT rules can be applied inside of a private WAN, if the gateway is NAT via PWAN Router. To avoid requiring specialized DNS server configuration inside the PWAN, users inside the private WAN network can access resources inside the PWAN via the public IPs (the IPs defined in port forward or NAT rules). This is known as hairpin NAT. However, hairpin NAT has the drawback of local requests being sent to the private WAN router, so a specialized DNS server will generally perform better.
Note
As per general IPv6 recommendations, features employing NAT do not support IPv6. See IPv6 Compatibility for a cheatsheet on the current state of IPv6 compatibility in bonding.
1:1 NAT¶
1:1 NAT rules forward inbound traffic for a single public IP to a single private IP in the PWAN.
Enabled¶
When checked, applies the rules on the PWAN routers.
Public IP¶
The IP of inbound traffic to match. Traffic bound for this IP will be NAT’ed to the private IP. This IP must be allocated to the space.
Private IP¶
The target IP of traffic matched by the public IP. This should be an IP of a host on any bond in the space.
Routing groups¶
The routing groups at which the NAT rule should be applied. The allocation which holds the public IP address must be valid at each of the selected routing groups.
Note¶
A free-form field for any relevant information.
Port forward¶
Port forward rules send inbound traffic matching the public IP, protocol, and port to a private IP and port in the PWAN.
Hairpin NAT can be inconsistent when multiple port forward rules are added for the same public port for different IPs.
Enabled¶
When checked, applies the rules on the PWAN routers.
Protocol¶
The protocol of inbound traffic to match.
Public IP¶
The IP of inbound traffic to match. This IP must be allocated to the space.
Public port¶
For protocols that use ports, the port number of inbound traffic to match. This can be a single integer or two colon-separated integers (i.e. “8000:8999”) to specify a range of ports.
Private IP¶
The target IP of traffic matched by the public fields. This should be an IP of a host on any bond in the space.
Private port¶
For protocols that use ports, the target port number of the NAT’ed traffic. This can be the same as the public port. This can be a single integer or two colon-separated integers (i.e. “8000:8999”) to indicate a range of ports. When a port range is specified, connections will be balanced among the destination ports.
Routing groups¶
The routing groups at which the port forward should be applied. The allocation which holds the public IP address must be valid at each of the selected routing groups.
Helper¶
Specify a helper module to assist Netfilter’s connecting tracking. In some cases, what an application considers a single connection is classified as different connections by the firewall. Helper modules exist to extend Netfilter’s behaviour in order to relate packets to connections given some knowledge about the application protocol. This is sometimes required in cases where failing to form the correct connections will break the application.
Note¶
A free-form field for any relevant information.