Proper support for duplicate iroutes.

This is where we can discuss what we would like to see added or changed in OpenVPN.
Post Reply
haggismn
OpenVpn Newbie
Posts: 15
Joined: Tue Dec 20, 2011 8:04 pm

Proper support for duplicate iroutes.

Post by haggismn » Sun Jan 15, 2012 3:16 pm

One missing feature in OpenVPN, which hinders deploying the application on a large, decentralised scale, is the ability to allow subnets to connect to one of a choice of servers, and maintain the same local connectivity. The problem is really quite simple, and is related to the iroute statements.

If I want to connect 2 servers together, this can be achieved through connecting one server to the other as a client. However if I want to give client subnets the choice of either server, things become much more complicated. Logically, the server connected as a client should have all the routes from the other server. The other server should also have iroute statements for the other server of all the subnets that may connect. This is so they can access both servers.

The problem is, only one iroute can exist for each subnet. This is a big headache if, like in my situation, duplicate iroutes are needed. Here is an example. On the primary server, the other server is connected.

Code: Select all

OpenVPN CLIENT LIST
Updated,Sun Jan 15 13:40:26 2012
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
SERVER-NCL
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
172.18.21.64/27,SERVER-NCL,
172.18.23.64/27,SERVER-NCL,
172.18.0.0/27,SERVER-NCL,
172.18.2.0/28,SERVER-NCL
172.18.1.0/28,SERVER-NCL
172.18.22.64/27,SERVER-NCL
172.18.254.2,SERVER-NCL
In this situation, any client belonging to those subnets above can join SERVER-NCL and then access anything thats on this server. However if one of those subnets connects to this server, the routing table changes like so.

Code: Select all

OpenVPN CLIENT LIST
Updated,Sun Jan 15 13:49:41 2012
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client1
SERVER-NCL
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
172.18.21.64/27,SERVER-NCL,
172.18.23.64/27,client1,
172.18.0.0/27,SERVER-NCL,
172.18.2.0/28,SERVER-NCL
172.18.1.0/28,SERVER-NCL
172.18.22.64/27,SERVER-NCL
172.18.254.2,SERVER-NCL
172.18.254.3,client1
You can see now that the 172.18.23.64 subnet has been inherited by client1. This works fine. However, from here on there are problems. Imagine a scenario where the link between this server and SERVER-NCL goes down and comes up again. SERVER-NCL will inherit the iroute for 23.64 back when client1, who is the user of this subnet, is still connected. This is because OpenVPN gives iroutes to clients who are most recently connected rather than evaluating who is using the subnet.

Code: Select all

OpenVPN CLIENT LIST
Updated,Sun Jan 15 13:56:01 2012
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
SERVER-NCL
client1
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
172.18.21.64/27,SERVER-NCL,
172.18.23.64/27,SERVER-NCL,
172.18.0.0/27,SERVER-NCL,
172.18.2.0/28,SERVER-NCL
172.18.1.0/28,SERVER-NCL
172.18.22.64/27,SERVER-NCL
172.18.254.2,SERVER-NCL
172.18.254.3,client1
Now nobody on client1 can use the vpn, apart from the router itself. The only way to solve this is to make client1's router reconnect so it gets the iroute priority back.

Another scenario occurs if the link doesn't go down. Say client1 leaves this server and joins SERVER-NCL. The connection on this server will timeout and the iroute will be removed from client1, however it will not be reinstated to SERVER-NCL

Code: Select all

OpenVPN CLIENT LIST
Updated,Sun Jan 15 14:02:24 2012
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
SERVER-NCL
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
172.18.21.64/27,SERVER-NCL,
172.18.0.0/27,SERVER-NCL,
172.18.2.0/28,SERVER-NCL
172.18.1.0/28,SERVER-NCL
172.18.22.64/27,SERVER-NCL
172.18.254.2,SERVER-NCL
Client1 in this situation can not access this server or anything attached to this server.

The first problem can be partially fixed by using a script to avoid placing the iroute in the ccd if the subnet is already connected. This is difficult if there are many subnets, however, and not effective if the subnet connects to a different server. The 2nd problem is one which cannot be avoided unless all client instances are killed and forced to reconnect. This is obviously not satisfactory.

Ideally, some kind of metric should be implemented. OpenVPN could then listen for this subnet to connect on any server it is specified on, and when it is heard from, it can automatically prioritise it correctly. When the subnet goes offline or switches and is heard from another server, the iroute can then update the metric when it learns an IP in that subnet from another server. Such a scheme would also take off reliance on there being a centralised server that all clients must go to to connect

Code: Select all

OpenVPN CLIENT LIST
Updated,Sun Jan 15 13:49:41 2012
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client1
SERVER-NCL
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref Metric
172.18.21.64/27,SERVER-NCL,
172.18.23.64/27,SERVER-NCL,...  1
(eg plus
172.18.23.64/27,SERVER-BCL,...  1
172.18.23.64/27,SERVER-LDN,  1
)
172.18.23.64/27,client1,...  0
172.18.0.0/27,SERVER-NCL,
172.18.2.0/28,SERVER-NCL
172.18.1.0/28,SERVER-NCL
172.18.22.64/27,SERVER-NCL
172.18.254.2,SERVER-NCL
172.18.254.3,client1
I have found temporary way around this problem, however it far from perfect. It involves specifying iroutes that are different, but use some of the same ip range and broadcast address. The subnet itself must then use the same number of hosts as the smallest specified iroute. This seems to allow proper switching, however it greatly reduces the number of subnets I can use. Here is an example. I have made the subnet smaller. SERVER-NCL thinks the subnet is larger, however no ips between 64 and 80 will ever be used;

Code: Select all

OpenVPN CLIENT LIST
Updated,Sun Jan 15 14:50:02 2012
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client1,
SERVER-NCL,
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
172.18.21.64/27,SERVER-NCL,
172.18.23.64/27,SERVER-NCL,
172.18.0.0/27,SERVER-NCL,
172.18.23.84C,client1,
172.18.254.3,client1,
172.18.2.0/28,SERVER-NCL,
172.18.1.0/28,SERVER-NCL,
172.18.0.1C,SERVER-NCL,
172.18.23.80/28,client1,
172.18.22.64/27,SERVER-NCL,
172.18.254.2,SERVER-NCL
I can switch between servers in this state and maintain connectivity to all local subnets. SSH sessions don't even log out.

What do you guys think? Such a feature cannot be that hard to implement, yet it could massively improve using the protocol on a larger scale LAN, if it didn't have to rely on having a centralised server to provide access to the LAN, and instead it could be delegated to other servers who clients could chose to connect to.
Bitcoin donations welcome: 1KLuGeTyyffB4F5bv6bi4hYm16PfmMuS8X

User avatar
Mimiko
Forum Team
Posts: 1568
Joined: Wed Sep 22, 2010 3:18 am

Re: Proper support for duplicate iroutes.

Post by Mimiko » Wed Jan 25, 2012 7:25 pm

So, behind server SERVER-NCL is a LAN 172.18.23.64/27, and bhind client1 is a LAN with same IP pool: 172.18.23.64/27.
This is addressed to connect remote sites which shares same IP pool. One way to resolve is to netmask:http://openvpn.net/index.php/open-sourc ... range.html
The best is to have different IP pools on perspective clients' LAN.

User avatar
dazo
OpenVPN Inc.
Posts: 141
Joined: Mon Jan 11, 2010 10:14 am
Location: dazo :: #openvpn-devel @ irc.freenode.net

Re: Proper support for duplicate iroutes.

Post by dazo » Tue Mar 20, 2012 8:58 am

Can you please try the --client-nat feature available in 2.3-alpha1 and see if that solves your issue?

camro
OpenVpn Newbie
Posts: 2
Joined: Sat Aug 05, 2017 1:36 pm

Re: Proper support for duplicate iroutes.

Post by camro » Fri Sep 20, 2019 8:55 am

is there any solution for that problem with iroute ?

as i have similar problem, that i have 2 redundant connection to main server1 -> and clients are server2(master) and server3(slave), but both clients are active/active connected.
and the route to internal network would be needed to add to both ...

server2 and server 3 are having the same internal network: 192.168.1.0/24

so, in my case i also would need to have 2 iroute ... basically like with priority(metric), then it would be working, but it seems to be, that iroute is still not having this functionality to use a metric for it.

and sometimes i loose the iroute ... don'T know how to see that - but will try with option: "management" and then to show the client and current internal routing.
is anyone having some scripts to read out, so, that i can disconnect clients that they are then reconnecting to handle that cases ?

cu camel

Post Reply