Network integration¶
SD-WAN is an advanced routing system that requires integration with a partner’s network. Three areas need to be integrated:
Firewall integration¶
SD-WAN requires a number of services to be available to hosts both inside and outside the partner network. The following table lists protocols and ports that must be available to the world. The ports must be open to the world because CPEs connect to these services for configuration and monitoring, and the network location of CPEs is rarely known in advance.
If you run a firewall in front of the management server or aggregators, you must ensure that these incoming protocols/ports are open in the firewall.
Management server¶
| Protocol | Ports/types | Service description | Built-in security measures |
|---|---|---|---|
| TCP | 22 | SSH | Connections allowed only from source IP whitelist |
| TCP | 80 | HTTP | None required; used for insensitive data only |
| TCP | 443 | HTTPS | TLS encryption |
| TCP | 4505, 4506 | SaltStack configuration management | AES encryption with automatically managed keys |
| UDP | 1194 | OpenVPN | TLS encryption with private certificate authority, HMAC |
| ICMP | all types | Network control and monitoring | None required; used for insensitive data only |
Aggregators¶
| Protocol | Ports/types | Service description | Built-in security measures |
|---|---|---|---|
| TCP | 22 | SSH | Connections allowed only from source IP whitelist |
| TCP | 8005 | Application monitoring from management server | TLS encryption with private certificate authority |
| UDP | recommended: all ports more restricted, if required: ports 2000 to 2000 + highest leg ID |
Tunneled traffic from bonders | Optional TLS encryption with private certificate authority optional HMAC authentication |
| ICMP | all types | Network control and monitoring | None required; used for insensitive data only |
| GRE | Tunneled PWAN traffic to/from PWAN routers | IPSec encryption using keys established via PWAN configuration and control socket | |
| UDP | 1999 | Wireguard | Wireguard encryption between aggregators in managed mesh PWAN configuration |
| UDP | 5789 | Tunneled PWAN traffic between aggregators | VXLAN tunnels between aggregators in managed mesh PWAN configuration (configurable) |
Private WAN routers¶
| Protocol | Ports/types | Service description | Built-in security measures |
|---|---|---|---|
| TCP | 22 | SSH | Connections allowed only from source IP whitelist |
| GRE | Tunneled PWAN traffic to/from aggregators | IPSec encryption using keys established via PWAN configuration and control socket |
Internal IPv4 networks¶
SD-WAN uses two networks for internal IPv4 communication:
- The network 10.250.0.0/16 is the management VPN, used for communication between nodes and the management server. Each node is assigned one IP from this network.
- The network 172.30.0.0/16 is the tunnel interface network. Each bond is assigned a /31 from this network, where the lower IP is assigned to the bonder’s tunnel interface and the upper IP is assigned to the aggregator’s tunnel interface. Since end-user traffic is forwarded through the tunnel interfaces, these IPs appear in traceroute commands.
Should these networks conflict with your environment, please contact technical support.
Internal IPv6 networks¶
SD-WAN uses two networks for internal IPv6 communication:
- The network fd00::/64 is the management VPN, used for communication between nodes and the management server. Each node is assigned one IP from this network.
- The network fd80:1::/32 is the tunnel interface network. Similar to IPv4, each bond tunnel uses two addresses from this network, one for the aggregator and one for the bonder. The addresses are deterministically calculated as a function of the bond ID.
Should these networks conflict with your environment, please contact technical support. Note that, since tunnel IPv6 addresses are deterministically calculated as a function of the bond ID, the tunnel interface IPv6 network cannot be changed.
In addition to these two networks, each tunnel interface on an aggregator will be configured with the address fe80:1::a, and each tunnel interface on a bonder will be configured with the address fe80:1::b. These are link-local addresses for communication between the bonder and aggregator over the bond tunnel.
Core routing integration¶
Aggregation servers are routers, forwarding packets from the partner datacenter routers to CPEs and back. They have internal routes for connected IP subnets, CPE NAT IPs, and routes, and these routes can be announced over OSPF, BGP, and Babel.
If a partner does not have dynamic routing in their datacenter network, static routes will need to be set up for each connected IP, CPE NAT IP, and route to the correct aggregator for each bond. If a bond needs to be moved from one aggregator to another, including if it is moved due to an automatic aggregator failover event, the static routes for that bond will need to be updated. This is tedious, error-prone, and slows down recovery in the case of a failed aggregator, so we strongly recommend partners to implement dynamic routing in their core networks.
Dynamic routing integration can be accomplished with Quagga, or entirely within bonding by configuring protocols and filters directly on nodes (this uses BIRD under-the-hood). Instructions for configuring Quagga are available at AN-002 Implementing dynamic routing in quagga. Instructions for configuring dynamic routing natively in bonding are available at Configuring dynamic routing in bonding. Configuring dynamic routing directly on nodes is strongly recommended over the use of Quagga as it is integrated into bonding and significantly more capable.
Leg routing integration¶
There are two types of bonder legs: (1) regular Internet connections, and (2) on-net, privately routed connections. Regular Internet connections require no special routing, because the ISP routes the traffic to any location on the Internet. On-net, privately routed legs must be routed such that they can contact the:
- Management server
- Aggregators
- DNS servers
Bonders must be able to contact the management server and aggregators at their regular, public IP addresses from both on-net and off-net legs. Bonders can use one or two DNS servers that are accessible only from on-net locations, but a third, publicly-available DNS server (such as Google public DNS) must be configured so that bonders with only off-net legs can still resolve DNS names.
Managed mesh integration¶
SD-WAN uses VXLAN interfaces to communicate between aggregation servers in the “Managed mesh” private WAN mode. This allows bonding to setup a private WAN network without the need of private WAN routers.
The vxlan interfaces communicate to each other via their set port. These ports must remain open, otherwise aggregation servers won’t be able to communicate.