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
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
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
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
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
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
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.