VPN bonding + bridging, is there failover for bridges?

Home Page Forums Network Management ZeroShell VPN bonding + bridging, is there failover for bridges?

This topic contains 3 replies, has 0 voices, and was last updated by  houkouonchi 9 years ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #42362

    houkouonchi
    Member

    Basically I am looking into options for the company I work for as they are moving to a new building and likely going to get five 10m/2m cable lines and instead of just load balancing them (and VPN traffic always being bottlenecked by a single link).

    The setup now (at the old office is):

    Dual T1 -> VPN/bonding router which bonds the two links and makes the 192.168.x.x private subnet show up as accessible from one of the vlans at the data center and thus machines on this subnet can access servers that are on the private vlan at the data center that are on 10.x.x.x. The nice thing about this setup is that the 10.x.x.x machines and 192.x.x.x machines have full access to each other (pretty much like they were on the same LAN as there is no need to forward ports and no NAT going on (atleast from the machines perspectives).

    What I have setup:

    For now I am just doing a test-bed setup simulating the otheroffice and the DC. I setup two servers in the DC, one which has two NICs and one connection is on the private 10.x.x.x subnet and the other is on a wan subnet (lets just say 208.x.x.x).

    For the other machine I used an atom box I had with 4 NICs. I hooked 3 of them up to one of our WAN switches and limited the switch speed to 10 meg (to just test things as i would be harder to test with everything being 100 meg). I got the VPN bonding working pretty well. If I bridge the bond interface (that goes over the 3 connetions) and the last NIC that will hook up to the ‘other offices’ LAN along with the two private vlan NIC + bonded VPN interface bonded on the DC box I was able to get pretty nice behavior.

    IE: I can just use an IP on the DC’s private subnet and it works as if the machines were hooked up to the switch inplace of the DC box. Each computer on the ‘other office’ LAN have pretty much non NAT’d access to other IPs on the 10.x.x.x private vlan subnet.

    The problem with this method is that the connection in the ‘other office’ will completely die if the VPN goes down for some reason. I wanted to have the ability to fail over the connection to non VPN based (the regular cable connections) if the VPN ever goes down for some reason. Is there a way I can do this in zeroshell? Like a failover for a bridge if say the VPN connection gets disconnected (BOND00 goes down)?

    The other method I did was leave the bridge on the DC box end and disable bridging on the ‘other office’ end. I instead enabled NAT over all ETH0X devices and BOND0. I then assigned an IP on the data centers private vlan to the BOND00 interface and went to the netbalancer and added a gateway that used that private subnets gateway and selected the BOND00 interface. I then changed it to just fail over mode (because under normal circumstances I want all traffic routed over the VPN for the aggregation. This worked as I would expect. Fail over worked great for disconneting the private subnet connetion from the DC box, disconnecting the WAN interface from the DC box (which also killed the VPN connections) or just removing individual links from the ‘other office’ box simulating one of the cable connections going down.

    The only problem with this method is that there is NAT between the two networks (due to it no longer being pure bridging) this means that all connections to say a server on the private 10.x.x.x subnet seem like they are comming from the same IP even if they are different machines on the ‘other office’s subnet. This is probably something I could live with but I figured I would ask to see if there is anyway to get around this and have it similar to how its setup now (except adding aggregation to the mix).

    Also it would be nice if the bonded VPN connection went down that it was load balanced over the three cable connections. I could get this behavior if I swithed from just fail over to failover + load balancing but the problem with that is that under normal circumstances (when the VPN is up) I want all traffic going through the VPN connection 100% of the time and it seems that setting a 99 weight to the VPN connection and 1 to all the rest would still allow (in rare cases) connections to not go through the VPN. If I could maybe set the weight at 1 million or something then it I would likely get what I want. I don’t think this is that big of an issue either though as I only expect this to happen in rare cases and thus it won’t kill people if they are only running off one 10/2 connection when this happens.

    So far I have been pleased with my tests on the aggregated connection. Using three connections that were switch limited to 10 meg I was able to get just under 28 megabits on downloads. The overhead appeared to be about 5% as the actual bandwidth over the Ethernet connections was around 29 megabits even though the downloads that were actually running on the DC box were 28 megabits.

    I am really considering doing a similar setup for my home system (have a box in the DC, etc..) once I move and get multiple connections that are the same speed. I have heard the VPN aggregation doesn’t work so well with different speed connections (nor would I expect it to especially with latency differences between the connections) so my current home with its DSL and uverse connection would likely not work very well using this method.

    Please let me know if anything was unclear or more information is needed.

    #50152

    houkouonchi
    Member

    Actually I just realized the way we were doing things at the old office was via openvpn connecting to a BSD server on our private network which was routing the two subnets together. From there our core router (on the private network which is cisco) used the ip route vrf command to connect that subnet to our private vlan. This seems to make the most sense and then I can completely drop the connection that was on a private VLAN on the DC zeroshell box which is better as I would rather not have a box that had a a phsyical connection to our private and public VLANs if avoidable and I would rather not be going through a NAT twice for all the regular connections (its a better solution in general with less routing going on).

    I am assuming that there should be no problem with having the *second* vpn connection going over the first VPN bond device so it is a nice aggregated connection?

    #50153

    ppalias
    Member

    You don’t need to worry about BOND00 failing. If you have at least one link of its members up it will be working. In case it stucks it is better to do a restart rather that thinking how to failover with the wan links.
    I might be a little tired now and not completely understand what you have and what you want to achieve so please if you could draw a picture of your wanna-have network.

    #50154

    houkouonchi
    Member

    @ppalias wrote:

    You don’t need to worry about BOND00 failing. If you have at least one link of its members up it will be working. In case it stucks it is better to do a restart rather that thinking how to failover with the wan links.
    I might be a little tired now and not completely understand what you have and what you want to achieve so please if you could draw a picture of your wanna-have network.

    My question was about bridging (not bonding). Basically I don’t think there was a good way to do quite what I wanted so I ended up going about it a different way (just have a second VPN connection for accessing our local network that goes over the bonded VPN connetion) instead of having everything bridged to give uses behidn the ZS box direct access to the network on the otherside as if they were plugged directly into the switch. This worked but unfortunately it would break the internet connection on the clients (which required the VPN/bridge to have internet access) if the bonded VPN connectino went down for some reason so I decided going the two VPN route is much better for what I want.

    #50155

    ppalias
    Member

    I suppose that you are covered now by the solution you chose. If you need some more help please also include a drawing fo what you have – what you want…

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.