Linux – Redundant OpenVPN connections with advanced Linux routing over an unreliable network

ip-routinglinuxnetworkingopenvpnrouting

I am currently living in a country that blocks many websites and has unreliable network connections to the outside world. I have two OpenVPN endpoints (say: vpn1 and vpn2) on Linux servers that I use to circumvent the firewall. I have full access to these servers. This works quite well, except for the high package loss on my VPN connections. This packet loss varies between 1% and 30% depending on time and seems to have a low correlation, most of the time it seems random.

I am thinking about setting up a home router (also on Linux) that maintains OpenVPN connections to both endpoints and sends all packets twice, to both endpoints. vpn2 would send all packets from home to vpn1. Return trafic would be send both directly from vpn1 to home, and also through vpn2.

       +------------+
       |    home    |
       +------------+
        |          |
        | OpenVPN  |
        |  links   |
        |          |
     ~~~~~~~~~~~~~~~~~~ unreliable connection
        |          |
+----------+   +----------+
|   vpn1   |---|   vpn2   |
+----------+   +----------+
        |
       +------------+
       | HTTP proxy |
       +------------+
             |
         (internet)

For clarity: all packets between home and the HTTP proxy will be duplicated and sent over different paths, to increase the chances one of them will arrive. If both arrive, the first second one can be silently discarded.

Bandwidth usage is not an issue, both on the home side and endpoint side. vpn1 and vpn2 are close to each other (3ms ping) and have a reliable connection.

Any pointers on how this could be achieved using the advanced routing policies available in Linux?

Best Answer

Use the bonding infrastructure at the 'home' and 'vpn1' side, and specifcally with the mode=3 setting which broadcasts traffic on all interfaces which belong to a bond.

For more information on how to configure bonding, see the excellent manual at http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.37.y.git;a=blob;f=Documentation/networking/bonding.txt;h=5dc638791d975116bf1a1e590fdfc44a6ae5c33c;hb=HEAD

Related Solutions

Iptables: combine SNAT with network remapping for OpenVPN

This is a big mess and you would honestly be better served by renumbering than by creating a web of ugly NATs with conflicting addresses. The other solutions you will need to support this (eg. split-horizon DNS with multiple zones, possibly with automatic updating) will be difficult and messy and every subsequent person who has to deal with this network will curse your name forever and burn effigies of you and your team.

Nonetheless, it looks like the problem you are having is that the hosts on one side of the NAT (see? I can't even describe the sides of the NAT properly, because it is messy) don't have a path back to hosts on the other side. You have to add a NETMAP rule for the return path too (packets incoming from eth1 I presume).

But wait! That's done in the prerouting chain. So, the destination address will be set before the routing decision is made, which is pretty much the way it has to work... but your router has two routes for the "conflicting" network. So, it will prioritize by the usual means (narrowest matching prefix first; metric to break ties), causing some packets to be reflected back onto the network they came from instead of being routed across the NAT. They will be source-natted too. Unfortunately, the source address isn't used in routing, so you can't use the source address. The input interface isn't used in routing either, and once the routing decision is made you can't rewrite the destination address again.

So, you find, this cannot be done. You have two options. Preferably, you would renumber one of the subnets with the network address conflict because you are a good network engineer rather than an incompetent one and you make networks that are not unnecessarily complicated. Renumbering VPN subnets tends to be an uncomplicated task which at worst will require the use of sed, but perhaps you have one of those weird situations where renumbering either subnet is an inhumanly difficult task. OK.

If for whatever reason you can't do that, you will need an additional router to go with your split-horizon DNS. Set up a router for each subnet (in effect this means one router for the VPN clients, and one router for the hosts on the network which unfortunately uses the prefix you'd staked out for the VPN). Pick some other address range (and it would have to be one you could otherwise renumber one of the subnets to...) to be the "foreign" one.

Now, suppose we call the network with the VPN hosts side A, and the network with the non-VPN hosts side B. Suppose on router A you choose the "foreign" prefix to be 192.0.2.0/24, and on router B, it's 198.51.100.0/24. These will be the fake prefixes you use for hosts on that subnet to contact hosts with the conflicted prefix on the other subnet (don't use these they're reserved for documentation purposes in RFC5737).

The below rules are complicated because you can't use the input interface as a predicate in the POSTROUTING chain, and the source subnet is non-unique, so we have to prevent spoofing using a filter rule. It's also confusing because NETMAP decides whether to change the source or destination address based on what chain it's in.

In router A and B, add a rule for incoming traffic on the point to point link between the routers which I shall call ptp0:

router-a # iptables -t nat -A PREROUTING  -i ptp0 -d 198.51.100.0/24 -j NETMAP --to 10.0.77.0/24
router-a # iptables -t nat -A POSTROUTING         -d 10.0.77.0/24    -j NETMAP --to 192.0.2.0/24
router-a # iptables -t filter -A FORWARD -i \!ptp0 -s 10.0.77.0/24 -j DROP
router-b # iptables -t nat -A PREROUTING  -i ptp0 -d 192.0.2.0/24    -j NETMAP --to 10.0.77.0/24
router-b # iptables -t nat -A POSTROUTING         -d 10.0.77.0/24    -j NETMAP --to 198.51.100.0/24
router-b # iptables -t filter -A FORWARD -i \!ptp0 -s 10.0.77.0/24 -j DROP

Now, this part of the problem is solved, because you no longer have a single router which has both prefixes in its routing table. No solution which requires you to have the same prefix referring to two different networks with two different hosts on them in the same routing table can work; it is intrinsically impossible because of how routing works.

Oh, and I almost forgot - I believe your SNAT rule is not getting processed because nothing is matching it, but it's important to remember that once a connection gets stored in the NAT state table, it no longer gets processed by the SNAT rule and no longer gets counted in the statistics if I recall.

If you don't actually require that the subnets be separate, just use layer 2 bridging. It will make your life a lot easier.

OpenVPN Tunnel between two LANs, traffic dropped on the way

in H1 try to add a route like this "route add -net 192.168.2.0/24 gw 192.168.1.10" and after that try to ping again, now if you want H1 and H2 ping each other, in H2 do the same, "rout add -net 192.168.1.0/24 gw 192.168.2.10"

In this the two pc in the two lans, they will use the vpn client and vpn server to reach the remote lan

Best Answer

Related Solutions

Iptables: combine SNAT with network remapping for OpenVPN

OpenVPN Tunnel between two LANs, traffic dropped on the way

Related Topic