Private WAN

Private WAN (PWAN) is the SD-WAN feature that allows geographically separated sites to securely route traffic to each other as if each site was connected to the same router. It also allows access to the Internet to be centralized for all bonds in a space.

Private WAN can be implemented in one of three modes:

• Mode: With private WAN routers
• Mode: Managed mesh
• Mode: Unmanaged

Note

With private WAN routers was the only private WAN type prior to 6.5. All private WAN deployments existing prior to 6.5 are of this type.

Tip

Managed mesh is strongly preferred over using private WAN routers for a number of reasons and is the recommended mode for new deployments.

For information on migrating an existing deployment using private WAN routers to a managed mesh, see migrating to managed mesh.

Capabilities

Private, secure routing

Spaces are the basis for private WAN. If PWAN is enabled for a space, all the bonds in the space route their traffic to and from each other through the aggregators (and possibly private WAN routers), rather than through the core public routers at each routing group. This allows the SD-WAN hosts to keep the space’s traffic isolated from the traffic of all other spaces. Spaces using PWAN will typically use private networks for connected IPs and routes, rather than public networks as are usually used for non-PWAN spaces. Aggregators and PWAN routers can route traffic for any number of spaces.

Though spaces are hierarchical for organization and access control in the management application, spaces are not hierarchical for routing purposes. Instead, each PWAN space is completely isolated from other spaces, even if they have a parent-child relationship in the management application.

Centralized Internet access

In addition to offering private routing among separate sites, private WAN also offers a way to centralize Internet access for all the bonds in a space.

Considerations

Bonder requirements

Prior to version 2016.2 there were no special system requirements for bonders. In 2016.2 and later, bonders part of a PWAN space must run Debian 7 (Wheezy) or later.

Aggregator requirements

Aggregators must run SD-WAN 2015.4 or later on Debian 7 (Wheezy) to host private WAN spaces.

Connected IPs and routes outside private WAN

Some network designs call for a mix of private WAN routing and normal public routing. For example, a bond may need to be part of a PWAN space but continue to use a public IP address for its connection to the Internet. This can be configured by disabling the “Include in private WAN” option on a bond’s connected IP or route. A bond can have multiple connected IPs and routes, some included in private WAN routing (these would typically be private addresses) and some excluded from private WAN routing (these would usually be public addresses). When a connected IP or route is not included in the private WAN, it is routed directly to the partner’s network via the aggregator just as it would be if the bond was not part of a PWAN space at all.

Because NAT is unnecessary in a PWAN space, CPE NAT IPs are always routed publicly, not as part of a PWAN space. A connected IP cannot be configured to be used in part of private WAN if it has a CPE NAT IP associated with it.

Performance

For performance and simplification of configuration, all bonds in a geographic region should be distributed across as few aggregators in the routing group for that region as possible, so long as the aggregators can handle that many bonds.

For example, if there are 40 bonds in a geographic region and four aggregators in the routing group for that region, the bonds should be distributed depending on the capacity of the aggregators as follows:

1. If the aggregators can handle 40 bonds each, all bonds should go on one aggregator.
2. If the aggregators can handle 20 bonds each, half the bonds should go on one aggregator and the other half should go on another.
3. If the aggregators can handle 10 bonds each, the bonds should be evenly distributed across all aggregators.

The balancing act here is that less aggregators in use for a space in a region means less overhead is spent running space environments, but too many tunnels on an aggregator can overload the aggregator’s I/O capabilities.

How to actually distribute your bonds in a region depends on the capabilities of the available aggregators and the bandwidth of the tunnels to distribute. As a rule of thumb, put 50 bonds on an aggregator in a region before adding a new aggregator to that region.

Limitations

Note

TCP proxy and all private WAN configurations are compatible as of version 6.0.

For versions up to and including 2016.2: The TCP proxy may not work for all private WAN configurations and may even interfere with certain configurations. If in doubt, disable the TCP proxy.