Question How to make 192.168.2.* accessible from 192.168.0.* ? (VPN)

[etho201]

Goal:
Make 192.168.2.* Accessible from 192.168.0.*

Situation:
I have a remote site (Network B) with an OpenVPN server built into the router. On my end I have a network (Network A) with a VPN client connected to the remote site (Network B). The host with the VPN Client can ping all systems in both networks.

Question:
How can I get hosts on Network A to communicate with hosts on Network B by first routing them through the host with the VPN client?
Note:I don't want them to each have their own VPN client.

Here is a diagram I created to make it more clear:

I tried the following:


On each machine in 192.168.0.* (Network A) a default gateway will be added as shown below.

$ route add default gw 192.168.0.3

In GATEWAY (This has my VPN client), add the following routing entry.

$ route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.2.47

At this point I hoped the machines in Network A could ping Network B, but they are unable to.

 

[Alabalcho]

Install a router with VPN client capability. Another solution would be to use Windows' RRAS (Router and Remote Access Service) as a gateway, but it runs on Windows Server, and will cost you much more than a router.

 

[bill001g]

The vpn client software needs to have this ability. Most are designed to run just a single client. Maybe ICS would work but many vpn clients do not have the interface used by ICS.

Your problem is you need some device to do NAT. All the ip addresses on the 192.168.0 network must appear as 192.168.2.47. Your problem with attempting to use actual routes is the devices on the 192.168.2.x network do not know to return the traffic back to 192.168.2.47 to get to 192.168.0.x .

This is why actual ROUTERS that can run routing protocols even exist. A pc is not a router and most so called consumer routers do not actually support mulitple subnets.

Don't know what to suggest. If you actually want this to route you will need a much more advanced setup. Otherwise you need to make all the traffic on the 192.168.0.x network share the vpn ip from the remote network.

 

[etho201]

I found a guide discussing NATs for this purpose, but couldn't quite get it to work ().

Otherwise you need to make all the traffic on the 192.168.0.x network share the vpn ip from the remote network.

These are Docker containers so that would be feasible -- anything routing through the VPN client computer/container is part of a mini network. How would I make all the traffic share the VPN IP? Any tips to get me going in the right direction are appreciated.

 

[bill001g]

I am not any where close a expert when if comes to IPTABLES in unix. I still think who ever wrote it intentionally made it confusing.

You can not just follow a generic guide you have to understand what the statement say.

My guess would be the output interface has to be the vpn not eth0 as they have configured. The vpn client likely has made changes to the iptables that you can display. You should be able to set the MASQUERADE option on that interface. Key is to make sure you get the nat and the vpn in the correct order. When it comes to IPTABLES I just guess until I get it to work I do it so seldom.

 

[etho201]

I've been doing lots of guessing and trial and error myself. Since these are Docker containers it's easy enough to rebuild in the event I mess anything up. I'll keep looking into the MASQUERADE option to see where that gets me. Thank you!

 

[etho201]

It looks like Docker has a way to automate the configuration of the MASQUERADE option. I will test this later.

com.docker.network.bridge.enable_ip_masquerade

--ip-masq

Enable IP masquerading

https://docs.docker.com/engine/reference/commandline/network_create/

In docker-compose it would look like this:

networks:
   front:
     driver: bridge
     driver_opts:
      com.docker.network.bridge.enable_ip_masquerade: 'true'

I will test this out later. If that doesn't work, I found a guide that seems to break it down and it looks pretty easy.

 

[failboat]

For vpns there are site-to-site setups where each client sees the others client ip. the tunnel ips are only used inside the tunnel.
if you check on your server at network b you probably see a remote connect as a tunnel ip. this works if services are only at one side and ip ranges can overlap for clients.
pfsense has automated site-to-site in their gui. you can run it as a vm on both sides. no ip ranges can conflict in this setup.

 

[etho201]

I will definitely take a look at pfSense. It seems to have some great features that I can probably take advantage of. Thank you!

As for my original question -- I figured it out. The MASQUERADE option in Docker does not seem to do anything automatically. I had to configure the iptables on the VPN client to act as a NAT with the MASQUERADE option, then I needed to add the VPN client's IP address on the respective interface as the default gateway on each system within that network.

Allow machines on the internal network (Network A) to communicate out to the external network (Network B)
You need to configure iptables to forward the packets from your internal network on eth1 (backend), to your external network on tun0 (remote).

1. On the machine running the VPN client

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT

2. On each machine within your internal network

route add default gw 192.168.0.3

3. Now the machines on Network A can ping/communicate with Network B.

Allow machines on the external network to communicate with your internal network
You need to configure iptables to forward the packets from your external network (Network B) on tun0 (remote), to your internal network (Network A) on eth1 (backend).

1. On the machine running the VPN client

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -i eth1 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -j ACCEPT

2. On each remote machine

route add default gw 192.168.2.47

3. Now the machines on Network B can ping/communicate with Network A.