ieee754's blunder blog

zeroshell, vpn bonding, and rdp

by IEEE754 on Dec.11, 2009, under zeroshell

i’ve been busy exploring zeroshell recently. i’ve stepped out of a pretty strict m0n0wall mindset to do so. with several m0n0walls deployed into production, a dozen perhaps, i’ve enjoyed the stability and simplicity. but i’ve been lured by zeroshell’s integration of openvpn and her promises of failover and loadbalancing functionality. were i live (australia) bandwidth comes at a premium thanks to a succession of numerous disfunctional governments and, perhaps more squarely, a lack of demand and market place drive. we are promised an NBN (national broadband network) revolution by the current elected pollies – but none of us are holding out breath.

so here we are; zeroshell to the rescue.

the scenario: i have one site with 4 adsl2+ links. another with a single adsl2 link. my intention is to serve TS (terminal services) hosted at site A to site B.

now, for those of you familiar with RDP, you will know that the key factor in the user experience is latency. latency is a product of two things;

a. the round trip time (eg. the ping)

+

b. the bandwidth available to meet redraw payloads

this is known as the bandwidth delay product or BDP for short.

in other words, the latency is the RTT plus the transfer time for the bitmap of the redraw.

you can have excellent < 10ms latency between sites – but without bandwidth in support, the ‘experience’ suffers. consider one of the ADSL2+ links at Site A syncing w/ 1MBit upstream . for a 128kbyte redraw over this link it quickly blows out beyond a full second!

its quite simple really, we need to increase the head room in our upstream bandwidth provided by Site A and reduce the RTT between sites.

the RTT might be out of your control – for the adsl links i deal with i switch to a line profile that disables interleaving – or ‘fast-pathing’ as its otherwise refered. as for the bandwidth restraints – openvpn bonding to the rescue!

the beauty of bonded VPN’s is the fact that it all takes place at the second lowest layer, otherwise referred to as ‘layer 2′. what does this mean? this is a big big deal. in simple terms it means that the links are aggregated transparently. it means a single TCP stream, such as our RDP sessions, can enjoy the total aggregated bandwidth of all of the VPN’s.

if you’ve ever aggregated network nic’s by bonding them together with a layer 3 switch in 802.3ab , you will be familiar with the limitations of layer 3 bonding – and delighted to hear that openvpn achieves bonding beneath it on layer 2!

the setup is quite straight forward;

Site A

1. each adsl link is established over a unique ethernet nic on the zeroshell

2. a unique vpn is defined for each link. each vpn is in server mode and its gateway and unique port are defined.

3. each vpn is bonded together to form a BOND00

Site B

1. the single adsl link is established over a nic on the zeroshell

2. a unique vpn is defined for each vpn at Site A, pointing to the corresponding link IP’s and ports

3. the vpn’s are bonded to form interface BOND00

with both sites configured in this manner the bandwidth is aggregated to reach a total of 4mbits. Site B also enjoys the redundancy of the for uplinks at Site A. if any of the links fail at Site A the corresponding VPN handshake fails and traffic is then routed over the remaining VPN links in the bond. In practice this translates to very low / minimal packet loss at the point in time that the link fails. naturally as links drop the aggregated bandwith does also.

i will follow up shortly with a step by step process w/ supporting captures of the zeroshell webgui to help you achieve this implementation.


4 Comments for this entry

Leave a Reply

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...

Archives

All entries, chronologically...