[resolved]Linking 2 VPN servers+routing movable subnets

[haggismn]

Hi there

I am trying to sort out our 2 servers, A and B. Both are set up exactly the same way with subnet topology. Their only difference is their location and public IP. The vpn server ip for A is 172.18.254.1 and for B, 172.18.1.1. I currently have the 2 servers linked, in that the more powerful server, B, has a 2nd instance of openvpn running as a client to A, and so it has 2 tun interfaces running, tun0 and tun1.

The issue I am having is that I would like to allow our client subnets to join either server, for example after choosing one by ping response time, and be able to communicate with any client subnet on either server. This is no problem setting on server A as far as I know, since only one tun interface is used.

The problem is that on server B, I need to specify the routes that may be attached to the server instance at some point. If those routes are specified on the server interface, tun0, but in actual fact they are on tun1 (ie the clients are connected to the other server), then it will not work if anyone attached to server B wants to talk to those on A, will it?

I believe I have the iroutes set up correctly, in that server B's client instance (tun1) is getting a push-reset and then being given some iroutes/routes to add in its ccd. However I have not pushed the route of the test client subnet (172.18.22.64) since I know this will not work; its already added on tun0. I would need to do this if I wanted to use 172.18.22.64 as a client of server A. I can access 22.64 from A when it is attached to B in this case.

Code: Select all

push-reset
push "topology subnet"
push "route 172.18.219.208 255.255.255.240 172.18.254.1"
iroute 192.168.1.0 255.255.255.0
iroute 172.18.22.64 255.255.255.224

The routing table of Server B

Code: Select all

omitted    *               255.255.255.255 UH    0      0        0 eth1
172.18.219.208  172.18.254.1    255.255.255.240 UG    0      0        0 tun1
172.18.1.0      *               255.255.255.240 U     0      0        0 tun0
172.18.254.0    *               255.255.255.240 U     0      0        0 tun1
172.18.22.64    172.18.1.1      255.255.255.224 UG    0      0        0 tun0
172.18.21.64    172.18.1.1      255.255.255.224 UG    0      0        0 tun0
omitted   *               255.255.255.0   U     0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default       omitted 0.0.0.0         UG    0      0        0 eth1

I was wondering if anyone can suggest what I should do in this case? Have I gone the right way in running a 2nd instance of openvpn on server B to get the 2 servers connected? is there any form of bridging of the interfaces I can perform, or can I reuse tun0 for the client instance with an extra option? Any advice would be much appreciated!

[haggismn]

To anyone concerned, I think I have accomplished the above by doing the following.

Server A, with only an OpenVPN server running, is assumed by default to have the routes to all of the client subnets. Server B's Openvpn server instance pushes server A's routes to its clients, with server B as the gateway. The client instance of Openvpn on server B then receives all of server A's routes in a ccd file with push-reset, so as not to have the gateway changed, and assumes those routes to be default. The ccd file also contains iroutes for all subnets that may connect to Server B.

Then on Server B I have put client-connect and Client-disconnect scripts which remove the route to Server A and add the same route, only with the gateway being Server B's openVPN gateway. Client-disconnect then removes this route and reinstates the previous assumption that server A will have access to the client subnets.

client-connect

Code: Select all

#!/bin/sh
if [ "$common_name" == "client1" ] ; then
route del -net 172.18.21.64 netmask 255.255.255.224 gw 172.18.254.1
route add -net 172.18.21.64 netmask 255.255.255.224 gw 172.18.1.1
fi
if [ "$common_name" == "client2" ] ; then
route del -net 172.18.22.64 netmask 255.255.255.224 gw 172.18.254.1
route add -net 172.18.22.64 netmask 255.255.255.224 gw 172.18.1.1
fi

client-disconnect

Code: Select all

#!/bin/sh
if [ "$common_name" == "client1" ] ; then
route del -net 172.18.21.64 netmask 255.255.255.224 gw 172.18.1.1
route add -net 172.18.21.64 netmask 255.255.255.224 gw 172.18.254.1
fi
if [ "$common_name" == "client2" ] ; then
route del -net 172.18.22.64 netmask 255.255.255.224 gw 172.18.1.1
route add -net 172.18.22.64 netmask 255.255.255.224 gw 172.18.254.1
fi

Server B's openvpn client instance uses the iroute and informs Server A when a member of client1 or client2's subnet connects, thus server A will use Server B as the gateway to that subnet, without having to change anything on server A. The only thing I haven't tested is having 2 clients, one being a subnet and the other being an individual, non iroute connect to Server B and see if they can contact each other. However the routing table is correct on Server B so I think this should work. The following is with client2 connected to Server B. I can contact anyone on Server A's subnet(172.18.219.208) and client1, connected to Server A. This is in spite of it being on the separate tun interface.

Code: Select all

omitted    *               255.255.255.255 UH    0      0        0 eth1
172.18.219.208  172.18.254.1    255.255.255.240 UG    0      0        0 tun1
172.18.1.0      *               255.255.255.240 U     0      0        0 tun0
172.18.254.0    *               255.255.255.240 U     0      0        0 tun1
172.18.22.64    172.18.1.1      255.255.255.224 UG    0      0        0 tun0
172.18.21.64    172.18.254.1    255.255.255.224 UG    0      0        0 tun1
omitted    *               255.255.255.0   U     0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         omitted 0.0.0.0         UG    0      0        0 eth1

To conclude, I can now have client subnets chose between multiple Openvpn servers, but allow them to have the same local access, independent of which conjoined server they chose.