Feature #11772
open
Layer 2 Tunnel Bonding Capability
Added by Clint Guillot about 3 years ago.
Updated almost 3 years ago.
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.
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.
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.
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.
Also available in: Atom
PDF
Updated by 
Updated by