Help for a sort of load balancing


I need help because I'm not able to find an answer to my question

I would like two (or more) openvpn connection on my router and when a new connection is established (when traffic come) a random VPN server is choosen

A sort of load balancing but to improve my privacy when browsing because the traffic will be shared across VPN servers configured

For example ;
I open in my browser and perhaps the traffic will go via VPN 1 or VPN 2 , if after I open perhaps the traffic will go to VPN 1 or VPN 2 and so on.. for all the traffic my router get

Do I need lots of RAM , CPU to do it ??

Do someone already did that or not ? Or someone can point me in the good direction ?

Thank you!!

It's like other multi-wan scripts. After running two instances of OpenVPN(tun mode), you can use either ip route nexthop weight or iptables mark+ip rule+ip route. The latter will create more randomness. 128MB RAM should be enough.

1 Like

Thank you

As you see I'm totally new to openwrt, do you have any links or concrete ways to do it

can this module crash ?

I use archer C7 from TP-LINK and I want to use openvpn on port 443

The Archer C7 isn't a "powerful" router by today's standards. Depending on your desired throughput, it may not have the CPU power to perform to your expectations. Each instance of OpenVPN will consume additional memory as well. With "only" 128 MB of memory, you may exhaust the memory, causing unexpected "crashes" of varying severity. My Archer C7, doing "nothing" except running the APs, no services offered, such as DNS, DHCP, NTP, consumes 27 MB of the 122 MB available.

You might want to consider what additional obscurity the complexity is gaining you. The security gains of such an approach are minimal, if any.

If you believe that it is worth the effort, more powerful hardware, such as an x86-based device with AES-NI capabilities would likely be valuable. You can route through that device, either before or after your Archer C7.

If you do decide to "randomize" the routing, you would need to have a given connection routed the same way each time. You can't have, for example, packet 1 going over VPN A and packet 2 going over VPN B.

Do you have tutorials links to do it or similar

I think what I want to do is not is not an option and I should do lots of manipulation right ? that mean more chance to misconfigure things

I just want something simple to have less occassion to do bad configuration or a service crashing etc etc

Do you think other firmware like ddwrt will be able to do that ?

It's my opinion that you're asking to do something that is well beyond what most people ask from VPN services. While some have asked that their VPN end point be chosen at random on connection, this is the first I have heard of a request that every connection be "randomized" across multiple VPN connections. I would be surprised if there is a "tutorial" for that out there in all the detail you might want.

I'd look at first getting your VPN up and running with a single end point. That will give you confidence that you've got that part configured properly, as well as the memory load of a VPN instance on your Archer C7.

You might then look at "multi-WAN" routing, which is a reasonably common application, where traffic is balanced across multiple links.

If one of your main goals is robustness/reliability in case one VPN service is unavailable or not working well, then simply using the "nexthop" method will give you a failure-tolerant system.

basically you do this somewhere:

ip route add default nexthop via VPNIPHERE dev vpn0 weight 1000 nexthop via VPNIP2HERE dev vpn1 weight 1000

which sends connections equally over both links (equal weights), fill in your tunnel endpoints IPs where I've put VPNIPHERE and replace vpn0 and vpn1 with the interface names you use.

You can learn more about this by googling on "linux multipath nexthop" or looking here:

EDIT: note near the bottom that hash based multipath works in kernels greater than 4.4, which includes LEDE's 4.9

thank you dlakelan and jeff :yum::smiley:

I'm happy your shared failure-tolerant system with me this was not I was looking after in my main message but I will definitively use it