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

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

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.

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