ieee754's blunder blog

i’ve moved onto my second deployment of zeroshell in as many weeks. after hitting my head against a brick wall for a few sessions i’ve found myself reading a great deal of the content in the zeroshell forums. with so many new users discovering zeroshell there is a lot to sift through – and the lack of official documentation certainly makes for a steep learning curve!

one of the key applications of zeroshell in my world is lan-to-lan vpn’s. secure, bonded, aggregated, and failover links between multiple sites. once setup zeroshell is rock solid delivering all of this and more. here is a crappy visio diagram that i’ve done up to illustrate the basic topolgy of my application;

there are a handful of examples of lan-to-lan setups on zeroshell.net linked too under documentation ( see here & here ), but many of the howto’s i came across suggest that a many-to-one link bond arrangement isn’t possible. or they simply don’t cover this scenario. others suggest that net balancing and vpn bonding should not be used in conjunction. if you have spent any time in the forums, you will have seen a lot of this repeated.

so which is it? do you need the same number of IP’s at each endpoint? no!

it IS definately possible to achieve a many-to-one setup. i will attempt to detail how i have gone about it here in this post;

1. Install Zeroshell at both sites;

• If you are giong for a physical install, install the image on some sort of RW media – flash / hdd / etc etc. There are is a great guide here thanks to Cristian Colombini. My only comment is that I have experienced difficulty using gunzip to directly write to SD media. I found by gunziping the image first, then using cat instead my problems disappear.
• If you are going for a virtual deployment, get the latest vmdk from the zeroshell downloads section. This has worked out of the box for me.
• Upon your first login to the GUI jump straight into the SSH configuration on the System Setup menu and enable it for your subnet. Its two steps – add your subnet – enable SSH. This has saved me numerous times – you will understand why soon enough.
• Setup and configure you WAN connections – for me I prefer PPP connections terminating at the Zeroshell itself. But there is a multitude of options before you. Plenty of info in the documentation section. Establish and be confident in your connection to the net before proceeding.
• Develop your chains. If chains are a new concept to you then some research will be required to bring yourself up to speed. IMMEDIATELY add accept rules to the OUTPUT chain for tcp ports 443 and 22 for you LAN interface – typically ETH00. Zeroshell’s chains are by default in an ACCEPT state – but I like to switch this to a DROP policy as soon as possible.

2. At the site with the single link (Site B above);

• Under VPN, define a VPN for each link at Site A. Again, plenty of documentation exists on this.

• Key points:

• for each VPN the ‘remote site’ field will contain the unique IP for a respective Site A link.
• for each VPN a unique port will be assigned – this is incremented automatically by Zeroshell.
• set each VPN  to Server mode
• select TCP or UDP – both work – however their pro’s and con’s are beyond the scope of this discussion. you can read more here. or just google ‘openvpn tcp vs udp’ and sift through the jungle!
• note the port to link relationships you establish
• select cert’s or generate keys using the provided generator
• add a private IP, on a unique subnet,  to each of the VPNs you define. eg. ip 192.168.101.1 netmask 255.255.255.0 . be mindful of clashes with your endpoint lans. (i’ve since found this step unnecessary)

• Define ACCEPT rules in the OUTPUT and INPUT chains for each VPN TCP/UDP ports on your PPP interface.

3. At the site with the multiple links (illustrated as Site A above) perform the following;

• Under the Net Balancer menu add each established link as a gateway, using labels you can identify them with later

• Enable the Net Balancer
• Under VPN, define a VPN for each link established.

• Key points:

• for every VPN the ‘remote site’ field will contain the IP for the Site B link.
• set each VPN  to client mode
• select TCP or UDP – whichever you elected at Site B.
• for every VPN select a unique gateway, as defined a moment ago under the net balancer menu
• for each VPN a unique port will be assigned – this is incremented automatically by Zeroshell
• pay close attention to ensure that for each VPN the port and gateway selected reflect the VPN defined at Site B
• select cert’s or copy and past the  keys generated for Site B earlier
• add a private IP, on the SAME subnet as defined by the retrospective VPN at Site B,  to each of the VPN defined. eg. ip 192.168.101.2 netmask 255.255.255.0

• Define ACCEPT rules in the OUTPUT and INPUT chains for each VPN TCP/UDP ports on your PPP interface.
• Under the Net Balancer menu define Balancing Rules for each of the VPNs you have defined based on their TCP or UDP port and interface. This is a critical step. I have captured an example to illustrate;

4. Review your VPNs at BOTH sites – each of them should now be able to establish a handshake. Review the VPN logs for any anomalies. Resolve any issues with them before proceeding.

5. Build a new BOND interface at each site.

• Do so through the Setup -> Network -> New Bond
• Add each of the VPNs to the BOND.
• Add a new IP address to the BOND -  use the same subnet as at the other end with a unique IP. ie. allocate 192.168.106.1 netmask 255.255.255.0 to BOND00 at Site A and 192.168.106.2, netmask 255.255.255.0 to BOND00 at Site B

6. Setup the Routing for the VPN

• Under the Routing menu add a new static route for traffic to be directed to the other site’s LAN. The following example is used to route to the 192.168.2.0/24 subnet at the other site;

select another unique

• Add a respective route at Site B for the subnet at Site A, pointing to gateway 192.168.106.1

7. Test!

• with these steps complete, Site B can enjoy the aggregate upstream bandwidth from Site A.
• use ping to ensure that echo sequences are without loss
• review the interface and VPN statistics and confirm that the BOND00 is in fact spreading the load

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.