Project

General

Profile

Actions

Feature #11772

open

Layer 2 Tunnel Bonding Capability

Added by Clint Guillot almost 3 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Multi-WAN
Target version:
-
Start date:
04/01/2021
Due date:
% Done:

0%

Estimated time:
Release Notes:
Default

Description

Ability to tunnel traffic over multiple WAN connections back to another PF appliance at a central location in order to aggregate bandwidth of the connections. This functionality is intended to allow the use of PF to compete against the bandwidth aggregation and failover functionality of products such as Velocloud.

This differs from the existing multi-wan failover and load balancing in two ways: 1. NAT is performed at the "central office" end of the tunnels, so that all traffic from customer appears to come from a single IP address and 2. because the tunnels are being bonded using some layer 2 method, the full aggregate bandwidth of both connections back to central is available to a single connection.

While #1 above can be done now using multiple tunnels and load balanced gateways, #2 is not currently possible. Though the real-world usefulness of #2 is limited to a small percentage of use cases, the "speed tests" most end users consider the most important metric of their ISP or "SDWAN" (drink!) solution fall into this group.

Actions #1

Updated by Clint Guillot almost 3 years ago

Bonus points on this one: A "wizard" which can be run on the "central office" end PF to create the configuration for both ends, providing something similar to the OpenVPN client exporter. Take the config bundle, import it onto the CPE PF, and we've got a pretty automated setup process. Come to think of it, this may be easier in reverse, taking the config bundle from the CPE to the CO, but I am not a software engineer, nor did I sleep at a Holiday Inn Express last night.

Actions #2

Updated by Kris Phillips almost 3 years ago

Not certain how this would be possible. Fundamentally internet connectivity doesn't work this way. You would need an upstream device on a big pipe that tunneled the traffic for you to accomplish something like this. Simply bonding two Layer 2 WAN connections together doesn't solve the problem of how you'd route at Layer 3. A better solution would be to improve existing load balancing in pfSense to have each new connection go through a different wan and give options to make it less or more "sticky" to each particular WAN. Speed tests, for example, allow multiple connections (speedtest.net, for example, has an option for single or multiple streams). If we were able to more intelligently manage multiple streams and allow pfSense to have tunables for more aggressive or less aggressive load balancing, I think this would be feasible.

Actions #3

Updated by Clint Guillot almost 3 years ago

I understand your concern about the requirement for an "upstream device on a big pipe," however this is exactly the situation we're trying to address. We're a small ISP with a small footprint, so serving customers beyond our fiber footprint starts with multiple connections from other vendors while we build toward the new customers. We do tunnel these connections back to one of our datacenters, which do have the "big pipes" you refer to.

Our biggest issue with this approach is, of course, upstream bandwidth. This issue usually crops up with customers using a cloud backup system or other vertical market specific solution which sends gobs of data over a single connection. In these situations, the ability to bond the two connections together and shoot them out to the cloud provider from our datacenter is the goal.

Actions

Also available in: Atom PDF