Layer 2 Tunnel Bonding Capability
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.
#1 Updated by Clint Guillot about 1 month 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.