==================
Space private WAN
==================

For more information on private WAN (PWAN), please refer to the `private
WAN documentation <../private-wan/index.html>`__. 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".

|pwan_mode|

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 <../private-wan/index.html>`__ for
details.


----------------------------
Managed mesh
----------------------------

Main article: `PWAN Managed mesh
<../private-wan/private-wan-managed-mesh/index.html>`__

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
<../private-wan/private-wan-unmanaged/index.html>`__

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 <../private-wan/private-wan-managed-mesh/migrating.html>`__
    for information on migrating an existing deployment using private WAN
    routers to a managed mesh.

Main article: `PWAN with private WAN routers
<../private-wan/private-wan-with-private-wan-routers/index.html>`__

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
<../private-wan/private-wan-with-private-wan-routers/gateways.html>`__.


Gateways for private WAN routers
--------------------------------------------------

There are three different types of gateways for private WAN routers,
as described in `Private WAN gateways
<../private-wan/private-wan-with-private-wan-routers/gateways.html>`__.
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.

|image0|

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.

|gateway-via-pwan-example|

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.

|gateway-via-bonder-example|

Here is an example of a configuration of connected IPs and routes on a bond
to support this gateway configuration.

|gateway-via-bonder-bond-example|

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 <../ipv6-compatibility/index.html>`__ 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.

.. |image0| image:: /attachments/11667027/12320821.png

.. |gateway-via-pwan-example| image:: /attachments/bonds/gateway-via-pwan-example.png
.. |gateway-via-bonder-example| image:: /attachments/bonds/gateway-via-bonder-example.png
.. |gateway-via-bonder-bond-example| image:: /attachments/bonds/gateway-via-bonder-bond-example.png
.. |pwan_mode| image:: /attachments/spaces/pwan_mode.png
