[SOLVED] Devices not communicating when using VPN to link two networks

7thSon · 2018-01-19 17:04:06

I'm trying to create a connection between my home LAN and an off-site location for remote backups. I've started a VPN server on the off-site router, and a VPN client in my home router, connecting the two.
The connection seems to work well, and it is set up to hold two subnets:

192.168.1.0/24 = My home network
192.168.2.0/24 = Off-site

The problem is that not all devices seem to be able to communicate between the subnets.
At home I have my desktop PC and a NAS, off-site there is only a NAS.

My desktop can ping the remote NAS and router successfully, but my local NAS can't ping neither the remote NAS or the remote router.
So for clarity:

Locally:
Router 192.168.1.1 VPN-client to 192.168.2.1 server running
My desktop 192.168.1.110 pings 192.168.2.1 successfully
NAS1 192.168.1.100 ping 192.168.2.1 unsuccessful

Off-site
Router 192.168.2.1 VPN-Server running
NAS2 192.168.2.100 ping 192.168.1.1 unsuccessful (and should be I guess, considering the local router is not hosting a server to allow traffic from off-site -> local)

The problem I believe is caused by a VPN connection to a VPN provider on my local NAS, which may or may not be affected by this masquerade script (below) I'm using to route traffic from my desktop to a specific ip by a static route.
If I disconnect my VPN connection to my VPN provider on my NAS (and keep the VPN server/client connection connected between my home and off-site) pinging from 192.168.1.100 to anything on 192.168.2.* works.

#!/bin/bash
#
# Change this variable to match your private network.
PRIVATE_NETWORK="192.168.1.0/24"
#
# Change this variable to match your public interface - either eth0 or eth1
PUBLIC_INTERFACE="tun0"

# Set PATH to find iptables
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin

# Module list where KERNEL_MODULES_NAT are defined.
IPTABLES_MODULE_LIST="/usr/syno/etc/iptables_modules_list"
source "${IPTABLES_MODULE_LIST}"

# Tool to load kernel modules (modprobe does not work for me)
BIN_SYNOMODULETOOL="/usr/syno/bin/synomoduletool"

# My service name - let's make sure we don't conflict with synology
SERVICE="NAT"

# iptable binary
IPTABLES="iptables"

start() {
	
	#clear iptables
	iptables -P INPUT ACCEPT
	iptables -P FORWARD ACCEPT
	iptables -P OUTPUT ACCEPT
	iptables -t nat -F
	iptables -F
	iptables -X
	
	
	# Log execution time
	date
	
	# Make sure packet forwarding is enabled.
	# 'sysctl -w net.ipv4.ip_forward=1' does not work for me
	echo 1 > /proc/sys/net/ipv4/ip_forward
	
	# Count the number of modules so that we can verify if the module
	# insertion was successful. We replace whitespaces with newlines
	# and count lines.
	MODULE_COUNT=$(
	echo "${KERNEL_MODULES_NAT}" |
	gawk '{ print gensub(/\s+/, "\n", "g") }' |
	wc -l
	)
	
	# Load the kernel modules necessary for NAT
	"${BIN_SYNOMODULETOOL}" --insmod "${SERVICE}" ${KERNEL_MODULES_NAT}
	RV=$?
	
	# $BIN_SYNOMODULETOOL returns the number of loaded modules as return value
	[[ "${RV}" == "${MODULE_COUNT}" ]] || {
		echo >&2 "Error: Modules were not loaded. The following command failed:"
		echo >&2 "${BIN_SYNOMODULETOOL}" --insmod "${SERVICE}" ${KERNEL_MODULES_NAT}
		exit 1
	}
	
	# Turn on NAT.
	"${IPTABLES}" -t nat -A POSTROUTING -s "${PRIVATE_NETWORK}" -j MASQUERADE -o "${PUBLIC_INTERFACE}"
	RV=$?
	[[ "${RV}" == "0" ]] || {
		echo >&2 "Error: MASQUERADE rules could not be added. The following command failed:"
		echo >&2 "${IPTABLES}" -t nat -A POSTROUTING -s "${PRIVATE_NETWORK}" -j MASQUERADE -o "${PUBLIC_INTERFACE}"
		exit 1
	}
	
	# Log current nat table
	iptables -L -v -t nat
}

case "$1" in
	start)
	start
	exit
	;;
	*)
	# Help message.
	echo "Usage: $0 start"
	exit 1
	;;
esac

I'm not very good at networking, so I don't really know how all of this works as I've pieced it together over time.
What is it that I need to do in order to get the local traffic to 192.168.2.* to work even when my NAS1 -> VPN Provider connection is active?

Last edited by 7thSon (2018-02-01 20:15:50)

lo1 · 2018-01-20 13:33:23

I'm not sure if I got your script right, but is it possible that you're just missing the rule for the actual route? Something like:

iptables -A INPUT -i tun0 -s 192.168.1.0/24 -d 192.168.2.0/24 -j ACCEPT #EDITED

Also, I don't know if you may need to specify ports and transport protocol since I never used iptables like this.

Last edited by lo1 (2018-01-27 18:40:06)

7thSon · 2018-01-20 23:32:01

lo1 wrote:

I'm not sure if I got your script right, but is it possible that you're just missing the rule for the actual route? Something like:
iptables -A FORWARD -i tun0 -s 192.168.1.0/24 -d 192.168.2.0/24 -j ACCEPT
Also, I don't know if you may need to specify ports and transport protocol since I never used iptables like this.

I see that I may have been a bit unclear on the masquerade script part.
The masquerade script is run on my local NAS, and on my desktop I have a route set up similarly as you suggest,
but with the purpose of routing traffic from my desktop via my NAS to a specific IP which is not related to the issue I'm trying to solve in this thread.

Should I still be able to put your suggested rule in my NAS iptables and get traffic between my two subnets?

lo1 · 2018-01-21 10:48:27

So, to recap: you just want to be able to get your devices to communicate when the VPN is up and running? If that's it, you should post any relevant configuration of the machines on both the subnets to understand where exactly the packets are being dropped. You can also use `traceroute`.

Adding that rule on your NAS may do the trick, but only if we're sure that the machines on 192.168.2.0/24 know how to reach 192.168.1.0/24 and the traffic is allowed.

I can't be more specific than this since I'm talking out of general knowledge, but posting any relevant configuration (vpn clients, vpn server, any firewall, any iptables rules) will make sure that me or someone else who jumps in this thread will be more likely to know exactly where the issue is.

7thSon · 2018-01-27 18:17:10

lo1 wrote:

So, to recap: you just want to be able to get your devices to communicate when the VPN is up and running? If that's it, you should post any relevant configuration of the machines on both the subnets to understand where exactly the packets are being dropped. You can also use `traceroute`.
Adding that rule on your NAS may do the trick, but only if we're sure that the machines on 192.168.2.0/24 know how to reach 192.168.1.0/24 and the traffic is allowed.
I can't be more specific than this since I'm talking out of general knowledge, but posting any relevant configuration (vpn clients, vpn server, any firewall, any iptables rules) will make sure that me or someone else who jumps in this thread will be more likely to know exactly where the issue is.

I will try to clarify my setup further:

My home router is setup with VPN client like this:
https://i.imgur.com/oNHpXY8.png
And the remote router is set up with a VPN server like this.
https://i.imgur.com/4jB8Yda.png

The two above are connected together and I can access the remote devices (192,168,2,x) from my desktop which is in the 192.168.1.x subnet.
In addition to the above VPN tunnel between the two sites my local NAS has an external VPN provider connection as well, this is the connection that seems to be causing the NAS to be unable to connect to (ping) anything on 192.168.2.x, since if I disconnect the external VPN provider connection I can successfully ping anything on 192.168.2.x.
Further the NAS has a masquerade script to route all traffic from my desktop PC via the NAS to a specific URL to go via tun0 (the external VPN provider connection), I don't know if this affects the issue I'm having.

#!/bin/bash
#
# Change this variable to match your private network.
PRIVATE_NETWORK="192.168.1.0/24"
#
# Change this variable to match your public interface - either eth0 or eth1
PUBLIC_INTERFACE="tun0"

# Set PATH to find iptables
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin

# Module list where KERNEL_MODULES_NAT are defined.
IPTABLES_MODULE_LIST="/usr/syno/etc/iptables_modules_list"
source "${IPTABLES_MODULE_LIST}"

# Tool to load kernel modules (modprobe does not work for me)
BIN_SYNOMODULETOOL="/usr/syno/bin/synomoduletool"

# My service name - let's make sure we don't conflict with synology
SERVICE="NAT"

# iptable binary
IPTABLES="iptables"

start() {
	
	#clear iptables
	iptables -P INPUT ACCEPT
	iptables -P FORWARD ACCEPT
	iptables -P OUTPUT ACCEPT
	iptables -t nat -F
	iptables -F
	iptables -X
	
	
	# Log execution time
	date
	
	# Make sure packet forwarding is enabled.
	# 'sysctl -w net.ipv4.ip_forward=1' does not work for me
	echo 1 > /proc/sys/net/ipv4/ip_forward
	
	# Count the number of modules so that we can verify if the module
	# insertion was successful. We replace whitespaces with newlines
	# and count lines.
	MODULE_COUNT=$(
	echo "${KERNEL_MODULES_NAT}" |
	gawk '{ print gensub(/\s+/, "\n", "g") }' |
	wc -l
	)
	
	# Load the kernel modules necessary for NAT
	"${BIN_SYNOMODULETOOL}" --insmod "${SERVICE}" ${KERNEL_MODULES_NAT}
	RV=$?
	
	# $BIN_SYNOMODULETOOL returns the number of loaded modules as return value
	[[ "${RV}" == "${MODULE_COUNT}" ]] || {
		echo >&2 "Error: Modules were not loaded. The following command failed:"
		echo >&2 "${BIN_SYNOMODULETOOL}" --insmod "${SERVICE}" ${KERNEL_MODULES_NAT}
		exit 1
	}
	
	# Turn on NAT.
	"${IPTABLES}" -t nat -A POSTROUTING -s "${PRIVATE_NETWORK}" -j MASQUERADE -o "${PUBLIC_INTERFACE}"
	RV=$?
	[[ "${RV}" == "0" ]] || {
		echo >&2 "Error: MASQUERADE rules could not be added. The following command failed:"
		echo >&2 "${IPTABLES}" -t nat -A POSTROUTING -s "${PRIVATE_NETWORK}" -j MASQUERADE -o "${PUBLIC_INTERFACE}"
		exit 1
	}
	
	# Log current nat table
	iptables -L -v -t nat
}

case "$1" in
	start)
	start
	exit
	;;
	*)
	# Help message.
	echo "Usage: $0 start"
	exit 1
	;;
esac

To use he above masquerade script my desktop PC has a static route set up to the NAS like this using a dhcpcd hook:

ip route add xxx.xxx.xxx.xxx via 192.168.1.100 dev enp5s0

And to answer your first question, yes what I want is for my local and remote networks (192.168.1.1 and 192.168.2.1) to be able to communicate when the external VPN provider connection is active. Note that this issue only affects the NAS which is not able to connect, my desktop PC does this just fine already.
So in summary, how do I get the NAS to have the external VPN provider connection active, while routing the desktop PC traffic as described above, and at the same time be able to reach 192.168.2.x?

Mod edit:
Changed pictures to links. Next time read and act upon the moderator's warning or requests.

Last edited by R00KIE (2018-01-28 11:59:56)

lo1 · 2018-01-27 18:37:45

Ok, thanks for the explanation. Try to edit the masquerade script to nat like this:

# Turn on NAT.
	"${IPTABLES}" -t nat -A POSTROUTING -s 192.168.1.110 -j MASQUERADE -o "${PUBLIC_INTERFACE}"
	RV=$?
	[[ "${RV}" == "0" ]] || {
		echo >&2 "Error: MASQUERADE rules could not be added. The following command failed:"
		echo >&2 "${IPTABLES}" -t nat -A POSTROUTING -s 192.168.1.110 -j MASQUERADE -o "${PUBLIC_INTERFACE}"
		exit 1

Basically, we're telling iptables that the forwarding rule you wish to add is true only for the host at 192.168.1.110 (I hope for you this will always be a static IP address, or things will get complicated). As it is, the rule is forwarding anything from 192.168.1.x to {PUBLIC_INTERFACE}. After the edit the NAS should nat the host and keep its own route to reach your external VPN provider. If you're not sure, you can just try to comment anything related to nat and see by yourself if the NAS has re-gained connection.

Also, note that I was wrong when I suggested to add a new rule in the INPUT chain, since it is already accepting anything:

#clear iptables
	iptables -P INPUT ACCEPT

EDIT: I've edited my first post because I suggested you to add the rule to "FORWARD", while I meant "INPUT". Sorry for the noise, anyway my last post stays theoretically correct.

Last edited by lo1 (2018-01-27 18:42:12)

R00KIE · 2018-01-27 18:46:07

@7thSon
Please don't post large images[1], either replace the images with thumbnails or with links.

[1] https://wiki.archlinux.org/index.php/Co … s_and_code

red-lichtie · 2018-01-28 00:47:34

Have you followed everything here: https://docs.openvpn.net/connecting/sit … in-detail/ or their trouble shooting guide (https://docs.openvpn.net/troubleshootin … pn-tunnel/) ?

7thSon · 2018-01-28 10:51:09

lo1 wrote:

Ok, thanks for the explanation. Try to edit the masquerade script to nat like this:
# Turn on NAT.
	"${IPTABLES}" -t nat -A POSTROUTING -s 192.168.1.110 -j MASQUERADE -o "${PUBLIC_INTERFACE}"
	RV=$?
	[[ "${RV}" == "0" ]] || {
		echo >&2 "Error: MASQUERADE rules could not be added. The following command failed:"
		echo >&2 "${IPTABLES}" -t nat -A POSTROUTING -s 192.168.1.110 -j MASQUERADE -o "${PUBLIC_INTERFACE}"
		exit 1
Basically, we're telling iptables that the forwarding rule you wish to add is true only for the host at 192.168.1.110 (I hope for you this will always be a static IP address, or things will get complicated). As it is, the rule is forwarding anything from 192.168.1.x to {PUBLIC_INTERFACE}. After the edit the NAS should nat the host and keep its own route to reach your external VPN provider. If you're not sure, you can just try to comment anything related to nat and see by yourself if the NAS has re-gained connection.
Also, note that I was wrong when I suggested to add a new rule in the INPUT chain, since it is already accepting anything:
#clear iptables
	iptables -P INPUT ACCEPT
EDIT: I've edited my first post because I suggested you to add the rule to "FORWARD", while I meant "INPUT". Sorry for the noise, anyway my last post stays theoretically correct.

I tried changing the masquerade script by setting the PRIVATE_NETWORK variable to 192.168.1.110, but that didn't solve the problem unfortunately.
It still behaves the same, as soon as I disconnect my external VPN provider connection the ping to 192.168.2.x is successful, but once it's connected again, ping fails.

Traceroute doesn't get anywhere from the NAS:

traceroute 192.168.2.100
traceroute to 192.168.2.100 (192.168.2.100), 30 hops max, 60 byte packets
 1  10.134.0.1 (10.134.0.1)  25.485 ms  26.291 ms  26.297 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *

lo1 · 2018-01-28 11:50:26

Then there's some overlapping routing decision happening. Investigate on the NAS with `ip route` (is it running arch, isn't it?)

7thSon · 2018-01-28 21:35:10

lo1 wrote:

Then there's some overlapping routing decision happening. Investigate on the NAS with `ip route` (is it running arch, isn't it?)

Here's the output from ip route:

$ip route
0.0.0.0/1 via 10.134.0.1 dev tun0 
default via 192.168.1.1 dev eth0  src 192.168.1.100 
10.134.0.0/16 dev tun0  proto kernel  scope link  src **public ip**
46.227.67.145 via 192.168.1.1 dev eth0 
46.227.67.147 via 192.168.1.1 dev eth0  src 192.168.1.100 
128.0.0.0/1 via 10.134.0.1 dev tun0 
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.100

lo1 · 2018-01-29 06:55:30

0.0.0.0/1 via 10.134.0.1 dev tun0

What is this route doing there? Forget it, leave it there. First try to add:

ip route 192.168.2.0/24 via 192.168.1.1 metric 0

and see what happens.

7thSon · 2018-01-29 07:05:17

lo1 wrote:

0.0.0.0/1 via 10.134.0.1 dev tun0 
What is this route doing there? Forget it, leave it there. First try to add:
ip route 192.168.2.0/24 via 192.168.1.1 metric 0
and see what happens.

Thats excellent, after doing

ip route add 192.168.2.0/24 via 192.168.1.1 metric 0

it's now possible to ping the remote NAS and router on 192.168.2.x!
But what was your concern with the first row of my ip route output?
It would be nice to fix/remove it if it's not necessary.

lo1 · 2018-01-29 07:42:12

Finally! That ip route is set up as soon as you bring up the VPN connection, and it seems to replace your default route by adding that strange route which, unless there's a more specific one, matches anything from 0.0.0.1 to 127.255.255.255 while

128.0.0.0/1 via 10.134.0.1 dev tun0

this one matches anything from 128.0.0.1 to 255.255.255.255 (search for longest bit match if you're not sure).

I don't know how to create a static route to be persistent upon reboot/VPN connections, but adding the route manually like this after connecting to the VPN will always make sure that you can reach that subnet.

If you're satisfied with the result, remember to mark your thread as [SOLVED].

EDIT: fixed the explanation, as always my posts are full of garbage.

Last edited by lo1 (2018-02-02 21:16:55)

7thSon · 2018-02-01 20:15:36

lo1 wrote:

Finally! That ip route is set up as soon as you bring up the VPN connection, and it seems to replace your default route by adding that strange route which, unless there's a more specific one matches anything from 128.0.0.0 to 255.255.255.255 (search for longest bit match if you're not sure).
I don't know how to create a static route to be persistent upon reboot/VPN connections, but adding the route manually like this after connecting to the VPN will always make sure that you can reach that subnet.
If you're satisfied with the result, remember to mark your thread as [SOLVED].

Huge thank you for the help, I've added the ip route command to my scheduled startup tasks on the server.
Marking as solved!

Arch Linux

#1 2018-01-19 17:04:06

[SOLVED] Devices not communicating when using VPN to link two networks

#2 2018-01-20 13:33:23

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#3 2018-01-20 23:32:01

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#4 2018-01-21 10:48:27

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#5 2018-01-27 18:17:10

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#6 2018-01-27 18:37:45

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#7 2018-01-27 18:46:07

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#8 2018-01-28 00:47:34

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#9 2018-01-28 10:51:09

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#10 2018-01-28 11:50:26

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#11 2018-01-28 21:35:10

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#12 2018-01-29 06:55:30

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#13 2018-01-29 07:05:17

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#14 2018-01-29 07:42:12

Re: [SOLVED] Devices not communicating when using VPN to link two networks

#15 2018-02-01 20:15:36

Re: [SOLVED] Devices not communicating when using VPN to link two networks

Board footer