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:

.. toctree::
    :glob:
    :maxdepth: 1

    private-wan-with-private-wan-routers/index
    private-wan-managed-mesh/index
    private-wan-unmanaged/index

.. warning::

    Private WAN routers will be deprecated in SD-WAN on August 1, 2025.
    Please see `Migrating to managed mesh <private-wan-managed-mesh/migrating.html>`__
    for information on migrating an existing deployment using private WAN
    routers to a managed mesh.

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


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:

#. If the aggregators can handle 40 bonds each, all bonds should go on one
   aggregator.
#. If the aggregators can handle 20 bonds each, half the bonds should go on one
   aggregator and the other half should go on another.
#. 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.
