0

I need to chain two subnets via VPS according to this schema:

192.168.1.0/24 -> VPN client -> VPS <- VPN client <- 192.168.2.0/24

So I want to reach, for example, 192.168.2.2 from 192.168.1.0/24 and viceversa. I created two OpenVPN tunnels such that 192.168.1.0/24 is connected to the first tunnel and 192.168.2.0/24 is connected to the second tunnel. Of course I setted up static routes adding 192.168.2.0/24 to local networks of the first tunnel and 192.168.1.0/24 to local networks of the second tunnel.

The problem is that I can’t reach anything from the clients.

Improve this question
3
  • Are you running VPN on the ROUTERS for each network? How are you routing between VPN (is what subnets/IPS is your VPN server handing out?
    – davidgo
    Oct 14, 2019 at 18:08
  • Yes, I have one pfSense firewall for each subnet with OpenVPN client succesfully connected to the server. The first one is connected to port 1194 and the second one to port 1195. Both OpenVPN servers (port 1194 and 1195) are running on the same VPS. About routing, I just pushed the 192.168.1.0/24 and 192.168.2.0/24 into the configuration such that 10.8.1.2 (pfSense client of the first subnet) is the gateway for 192.168.1.0/24 and 10.8.2.2 (pfSense client of the second subnet) is the gateway for 192.168.2.0/24
    – user544490
    Oct 14, 2019 at 18:11
  • You should probably be doing this with a single OpenVPN server rather then 2. There are a few potential problems - the first could be that the VPN VPS is not forwarding packets (either at the kernel level or iptables forwarding rules). The second - and where I suspect your problem is, is that you need OpenVPN to interact with the kernel routing tables. You probably need "route" commands in your OpenVPN config, along with iroute commands in the config for each client.
    – davidgo
    Oct 14, 2019 at 18:55

1 Answer 1

Reset to default
0

I actually have used something similar in order to get connection to my home network, from the Internet.

My home network is behind a Carrier Grade Network, so I have to jump through al sets of hoops in order to use VPN.

The downside: Very poor performance, when we are measuring bandwith over VPN vs raw Internet connection.

Hint: I have a 300/300 Mbps connection, but I have measured at most 17 Mbps over VPN.

I use OpenVPN as my VPN server. Mainly because I need a VPN server that supports TCP packages, since I can't keep a VPN connection alive via UDP.

It is so bad that I need to set my keepalive timer to 10 seconds or shorter, or else the Carrier Grade NAT will drop my VPN connection from my home network to the VPN server. :-(

So my recommondation: If you want the best performance of your VPN connection. Switch to UDP packages if it is a possibility.

DISCLAIMER:

My VPN net is currently inactive, so the information provided below may have a typo here and there, but the general idea should work.

Anyway. Onwards to my setup:

Network schematic for my VPN net

Most of the magic happens on the VPN server.

Each of my client connects to my server using a unique client certificate. I use the provided CommonName from the client certificate to lookup in the client configuation directory for further settings.

My VPN server is hosted in a VPS hosted facility (TransIP.eu), which is located in a completely different country than myself. I choose them because they were cheap and the VPN server has a really fast connection to the Internet (10 Gbps).

You don't need to use my VPS provider. Anyone can do, as long as you have access to configure OpenVPN yourself. :-)

My solution is basically built on this:

OpenVPN multiple clients on routed TUN

The important lines in my server.conf:

# The actual VPN net. 
# Each VPN client connected to the VPN server can ping each other 
# on the 192.168.100.0/24 subnet.

server 192.168.100.0 255.255.255.0

# I can't really remember if I need to push the 192.168.100.0/24 subnet 
# from the general settings to the client.
#
# All VPN clients gets an IP address from this range.
#
# Comment it out if not needed. 
push "route 192.168.100.0 255.255.255.0

ifconfig-pool-persist ipp.txt

# Location of the client specific configuration files.
# It is in the 'ccd/' subfolder.

client-config-dir ccd

# Neccessary so that each VPN client can see each other (aka 'ping'). 
client-to-client

In my ccd subfolder I have the following files:

RasberryPi4
MyFriend

The content of the file RasberryPi4:

ifconfig-push 192.168.100.2 255.255.255.0
push "route 192.168.0.0 255.255.255.0 192.168.100.3 1"
iroute 192.168.1.0 255.255.255.0

The content of the file MyFriend:

ifconfig-push 192.168.100.3 255.255.255.0
push "route 192.168.1.0 255.255.255.0 192.168.100.2 1"
iroute 192.168.0.0 255.255.255.0

Now this assume that client connect the VPN server with a client certificate that has the CommonName "RasberryPi4", while the other client certificate has the CommonName "MyFriend".

There are no special file for my cell phone, so when it connects to the VPN server it gets assigned an available ip address on the 192.168.100.0/24 subnet, but it cannot reach either the 192.168.0.0/24 or 192.168.1.0/24 subnet.

If I want to reach both subnets and my phone certificate has the CommonName MyPhone, then I need another file in ccd subdirectory named MyPhone with at least these minimum settings:

push "route 192.168.0.0 255.255.255.0 192.168.100.3 1"
push "route 192.168.0.0 255.255.255.0 192.168.100.2 1"

I have also expanded on the configuration above, so I could split a /48 IPv6 subnet from Hurricane Electric so my friend and I had each our own /56 IPv6 subnet at home, which could be accessed by everybody that has an IPv6 address.

... but that is a completely different story. :-)

Hope this helps. :-)

Improve this answer
13
  • @LasseMichaelMelgaard There is no compelling reason OpemVPN needs to be slow, but I suspect your hardware choice may make a big difference. I can pill much better speeds through my ASUS 1900 routers, and, of-course x86 PCs. Also, out of curiosity, were you using TCP or UDP?
    – davidgo
    Oct 15, 2019 at 1:17
  • I was forced to use TCP with a keep alive at 10 seconds or less due to my CGN. I would prefer if my ISP implement IPv6 all the way to my endpoint, since it would make VPN much easier. Alas my ISP is amateurs, so that ain't gonna happen before maybe next decade.
    – Lasse Michael Mølgaard
    Oct 15, 2019 at 6:16
  • I expect the TCP stuff contributes to the slowdown. Your ISP must suck rocks if they don't handle UDP properly.
    – davidgo
    Oct 15, 2019 at 6:24
  • I'm guessing only 5 public IP addresses available to the CGN - with several thousands BEHIND the CGN. It leads to congestion at the CGN, meaning it will drop TCP and UDP session state very fast. A short keep alive is a trick to prevent it from dropping the session, but only works for TCP.
    – Lasse Michael Mølgaard
    Oct 15, 2019 at 6:55
  • Thank you for the suggestions. Now I can ping from the VPS the client at 192.168.1.40 but not the other clients in my network, for example 192.168.1.6. Should I add static routes in my client?
    – user544490
    Oct 15, 2019 at 13:25

You must log in to answer this question.