VPN Bonding: Pushing through the challenges!

New Foundations #1 – VPN Bonding – Pushing through the challenges.
by Wylie Bayes

VPN Bonding
Hey everyone! Wylie is back in action and this topic is all about VPN bonding and the challenges you can face when coming up with a solution that is right for your organization.

I know many organizations are still utilizing private leased lines from phone companies such as Century Link. These private lines can cost a place a fortune, especially with multiple locations involved. Not to mention they are slow and even with a service agreement.. can fall short on reliability… So what is a place to do? Well the first major thing to be concerned about when thinking of a VPN bonding solution is location. Where your organization has locations and what consumer broadband services are available in those area’s. More than likely if you can get a private MPLS line to a location, you probably have some type of broadband options. Multiple broadband options from different service providers is desired for best results.

The Equipment:

1. Cisco routers 1900 series routers.
2. Peplink Balance 580 and 380 VPN bonding appliances.
3. Fortigate / PFSense(custom) firewalls.
4. Some Gigabit ethernet switches. (This can vary depending what you have available)
5. Ubuntu 11.1 box and a Windows XP laptop.

The Testing:
The lab we setup simulated VPN bonding at 3 locations. We had our Peplink balance 580 at the Main location, and two balance 380?s at the remote locations. Each location had a Cisco 1921 router on the LAN interface of its respective peplink. Also we placed a Firewall in front of the WAN connections at each Peplink in a transparent filtering mode.

We then setup another Cisco 1921 to simulate the Internet. We separated each peplink into it’s own public network. 1.1.1.0/24, 2.2.2.0/24, 3.3.3.0/24. Internet router IP’s were .1 on each subnet, and each peplink device was .5 on each subnet. Once all the configurations were in place, and routing was possible, the peplink units would successfully sync up and begin their Voodoo magic bonding arrangement. Of course the peplink units had to be configured correctly with the configuration mentioned above.

The challenge:
So things at my organization are fairly simple in terms of routing. We utilize EIGRP as our IGP. Then we have BGP configured with our lease provider. The lease lines basically just create a huge bridge between all our locations and routing occurs naturally with EIGRP.. nothing stands in the way. With a VPN bonding solution, and consumer broadband, this does not occur naturally.
We investigated and researched different products to see what solutions were out there to include a Dynamic routing solution from one of these VPN bonding appliance vendors. The options were very slim. We found a few places such as Xroadsnetworks, and Riverbed that had options built in for RIPv2 and OSPF.
We also investigated creating a Layer2 bridge with the bonding appliances and creating a big local network between all the locations. This solution is possible however it is impossible to control the broadcast traffic on the network. You can stop it once it reaches the LAN side of a peplink and the Cisco router cuts off the broadcast domain and begins routing again… but that still brings the traffic all the way accross your bonded connection eating up precious bandwidth for no reason, just to get dropped by a router at the LAN side… not a very good solution.

Before we decided to order other appliances such as Xroads, or Riverbed, it occurred to us that we could more than likely establish a GRE tunnel from one LAN side Cisco router to another with tunnel interfaces. This proved true. EIGRP could easily be configured now to advertise it’s tunnel interface IP for routing. Not only for routing updates, but for ALL traffic from site to site. Everything is pushed through the tunnel interface by default at each location. This is also a amazing solutions because it completely hides how the traffic gets from one location to another. A traceroute will only show 2 hops, vs 50 across the internet.

Now that we have a way to make Cisco’s talk through this VPN Bonded Voodoo magic tunnel, the problem of dynamically updating your own routers is solved, and traffic from location to location is even more protected. You could even take it a step further and utilize an IPSec tunnel from Cisco to Cisco vice a GRE tunnel. This would be an encrypted tunnel inside of Peplink’s encrypted/bonded tunnel. We don’t really see the need for double encryption at this time as it adds more overhead, but I suppose if you have the bandwidth it wouldn’t be an issue in most cases.

Once we figured out the tunnel situation we realized it didn’t matter what VPN Bonding appliance we used, we would get our Cisco’s to talk the same way. Peplink is one of the lower end vendors in terms of pricing.. But our testing proved that the Bonding is actually very good. We could get some very HIGH speeds in our lab environment. Also the resilience of recovering connections between peplinks was very solid. Recovery times when a link went down to re-establish were excellent. These are really the only key features we needed for the actual bonding appliance.

Finally, we had to ensure we could protect the WAN side interfaces as to prevent some type of intrusion into one of the Peplink devices. We successfully configured a Fortigate 60c as well as a DL380 g3 server with PFsense in a transparent bridge mode to filter traffic from ISP’s going into the WAN interfaces on the peplinks. Filter rules were created to only allow traffic from peplink IP addresses to ensure their tunnels could establish, but all other traffic is deny’d. Rules for internal network traffic are unnecessary because all traffic is hidden inside the GRE tunnel. The WAN side firewalls cannot inspect it’s contents. However, anything coming from the internet inbound is sure to be denied.

In this particular arrangement all traffic from remote locations must travel through a Tunnel interface back to the Main location in order to get anywhere, IE: the actual internet. This protects the remote locations and ensures they are private, just as in the current Lease Line scenario.

If you have two broadband connections each with 25mbit…. the peplink units will combine those two connections and will result in 50mbit connection speed. The appliances devide packets between connections and re-assemble them at the distant end. So with three 25mbit connections your maximum throughput would be 75mbit. This bonding works with traffic going through a GRE/IPSec tunnel thus creating a MASSIVE amount of bandwidth from location to location for a Fraction of the cost of MPLS leased lines. Not only the cost… but the speed of broadband connections is far better than private lines in terms of the cost comparison.

The solution works. You can completely DO-AWAY with private lines and create the same scenario with consumer broadband. Increasing your speeds, and cutting costs. It is a wonderful amazing solution for any organization. If you have any questions or would like to know anything more specific about our testing please comment! Thanks everyone!
-Wylie