Using OpenVPN to connect home, but cannot RDP to machines that are routed through VPN client

[madfusker]

I have PIA running on my router with the client policy shown below. So only my router and desktop are excluded from going through my PIA VPN that is running on the router. I also have a laptop that by default routes through the VPN due to the /24 rule and is on 192.168.1.20. My problem is that when I remotely connect with my Android phone to my router via OpenVPN (FYI-it assigns 10.8.0.2 to my phone), I can only connect to the excluded machines on the WAN, and not my laptop that is inside the PIA VPN on the router.

Is there a way I can connect to all machines on my network when I VPN home so I can manage them regardless if they are on or off the VPN? and what rule would allow this?

VPN client Policy Rules using PIA VPN (strict):
All LAN 192.168.1.0/24 0.0.0.0 VPN
Router 192.168.1.1 0.0.0.0 WAN
Desktop 192.168.1.10 0.0.0.0 WAN

I had this working well at one time, but somehow lost the setting that enabled it. :/

 

[madfusker]

Here is more info:

admin@RT-AC86U-E9D8:/tmp/home/root# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 21-107-112-1.dh 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 * 255.255.255.0 U 0 0 0 tun21
21.107.112.0 * 255.255.240.0 U 0 0 0 eth0
21.107.112.1 * 255.255.255.255 UH 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
192.168.1.0 * 255.255.255.0 U 0 0 0 br0
admin@RT-AC86U-E9D8:/tmp/home/root#​

 

[wiz]

your pc gets a 10.8.0.x ip address when connected to vpn. Therefore your machines that you want to RDP to need to know how to get to the network 10.8.0.0/24. Since it is outside their own lan they will go to your asus. Therefore you will need to put a static route in yr asus to route 10.8.0.0/24 through the ip address that yr tun21 device has. Then it should work.

 

[Martineau]

I have PIA running on my router with the client policy shown below. So only my router and desktop are excluded from going through my PIA VPN that is running on the router. I also have a laptop that by default routes through the VPN due to the /24 rule and is on 192.168.1.20. My problem is that when I remotely connect with my Android phone to my router via OpenVPN (FYI-it assigns 10.8.0.2 to my phone), I can only connect to the excluded machines on the WAN, and not my laptop that is inside the PIA VPN on the router.

Is there a way I can connect to all machines on my network when I VPN home so I can manage them regardless if they are on or off the VPN?

Allow WAN RDP access to a LAN PC that is routed via OpenVPN Client

 

[madfusker]

@Martineau Pure genius, thanks! But still a small issue with loading on boot.

Here is what I did:
Created a /jffs/scripts/nat-start file with an entry for each machine:

#!/bin/sh
touch /tmp/000wanstarted
ip rule del fwmark 0x7000/0x7000 2> /dev/null
ip rule add fwmark 0x7000/0x7000 table 254 prio 9990
ip route flush cache
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.3 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.3 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.4 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.4 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.6 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.6 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.3 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.3 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.4 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.4 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.6 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.6 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000

Then did a chmod a+rx /jffs/scripts/*

I used a "touch /tmp/000wanstarted" in the script, so I know that it's getting executed on boot, but it doesn't load everything in my script. Only the last entry for 192.168.1.6. Is it possible it gets executed too early in the nat-start file and should come later? Or should this be in a different file?

Results after boot:

admin@RT-AC86U-E9D8:/tmp# iptables -nvL PREROUTING -t mangle --line
Chain PREROUTING (policy ACCEPT 48204 packets, 25M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1    13809 9837K MARK       all  --  tun11  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
2       27  1689 MARK       all  --  tun21  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
3        0     0 MARK       udp  --  br0    *       192.168.1.6          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
4        0     0 MARK       tcp  --  br0    *       192.168.1.6          0.0.0.0/0            multiport sports 3389 MARK or 0x7000

and if I manually run the script they are all there as expected:

admin@RT-AC86U-E9D8:/tmp# /jffs/scripts/nat-start
admin@RT-AC86U-E9D8:/tmp# iptables -nvL PREROUTING -t mangle --line
Chain PREROUTING (policy ACCEPT 46 packets, 4664 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1    17820   13M MARK       all  --  tun11  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
2       28  1762 MARK       all  --  tun21  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
3        0     0 MARK       udp  --  br0    *       192.168.1.3          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
4        0     0 MARK       tcp  --  br0    *       192.168.1.3          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
5        0     0 MARK       udp  --  br0    *       192.168.1.4          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
6        0     0 MARK       tcp  --  br0    *       192.168.1.4          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
7        0     0 MARK       udp  --  br0    *       192.168.1.6          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
8        0     0 MARK       tcp  --  br0    *       192.168.1.6          0.0.0.0/0            multiport sports 3389 MARK or 0x7000

How can I get the script to load all 3 machines at boot instead of only the last one?

 

[madfusker]

Just for fun I tried to insert a "sleep 10" into the script right after all the -D lines, but before the -A lines.

admin@RT-AC86U-E9D8:/tmp/home/root# cat /jffs/scripts/nat-start
#!/bin/sh
touch /tmp/000wanstarted
ip rule del fwmark 0x7000/0x7000 2> /dev/null
ip rule add fwmark 0x7000/0x7000 table 254 prio 9990
ip route flush cache
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.3 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.3 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.4 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.4 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.6 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
iptables -t mangle -D PREROUTING -i br0 --src 192.168.1.6 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000 2> /dev/null
sleep 10
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.3 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.3 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.4 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.4 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.6 -p udp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
iptables -t mangle -A PREROUTING -i br0 --src 192.168.1.6 -p tcp -m multiport --sport 3389 -j MARK --set-mark 0x7000/0x7000
admin@RT-AC86U-E9D8:/tmp/home/root#

Then rebooted and I get 3 copies of each machine. I am puzzled. :/ In the logs it looks like the script is executed before ovpn-server and ovpn-client, could this be the problem that it needs to be after?

admin@RT-AC86U-E9D8:/tmp/home/root# iptables -nvL PREROUTING -t mangle --line
Chain PREROUTING (policy ACCEPT 11734 packets, 4246K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     2004 1010K MARK       all  --  tun11  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
2        7   413 MARK       all  --  tun21  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
3        0     0 MARK       udp  --  br0    *       192.168.1.3          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
4        0     0 MARK       tcp  --  br0    *       192.168.1.3          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
5        0     0 MARK       udp  --  br0    *       192.168.1.4          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
6        0     0 MARK       tcp  --  br0    *       192.168.1.4          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
7        0     0 MARK       udp  --  br0    *       192.168.1.6          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
8        0     0 MARK       tcp  --  br0    *       192.168.1.6          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
9        0     0 MARK       udp  --  br0    *       192.168.1.3          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
10       0     0 MARK       tcp  --  br0    *       192.168.1.3          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
11       0     0 MARK       udp  --  br0    *       192.168.1.4          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
12       0     0 MARK       tcp  --  br0    *       192.168.1.4          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
13       0     0 MARK       udp  --  br0    *       192.168.1.6          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
14       0     0 MARK       tcp  --  br0    *       192.168.1.6          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
15       0     0 MARK       udp  --  br0    *       192.168.1.3          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
16       0     0 MARK       tcp  --  br0    *       192.168.1.3          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
17       0     0 MARK       udp  --  br0    *       192.168.1.4          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
18       0     0 MARK       tcp  --  br0    *       192.168.1.4          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
19       0     0 MARK       udp  --  br0    *       192.168.1.6          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
20       0     0 MARK       tcp  --  br0    *       192.168.1.6          0.0.0.0/0            multiport sports 3389 MARK or 0x7000
admin@RT-AC86U-E9D8:/tmp/home/root#

 

[madfusker]

Alright, after a bunch of messing around it seems that my results are a bit random after a fresh boot. Sometimes 1 machine is loaded, sometimes 2, sometimes 3. And sometimes just one machine with only tcp. I believe this script must be executed later on after everything is up and running. Can anyone suggest how to execute it after everything is up and going? Given I can execute it from the command prompt with good results, it seems like this would solve my problem.

 

[Martineau]

Alright, after a bunch of messing around it seems that my results are a bit random after a fresh boot. Sometimes 1 machine is loaded, sometimes 2, sometimes 3. And sometimes just one machine with only tcp. I believe this script must be executed later on after everything is up and running. Can anyone suggest how to execute it after everything is up and going? Given I can execute it from the command prompt with good results, it seems like this would solve my problem.

Here is my nat-start script template... see if it solves your @boot run-time issues

#!/bin/sh

Say(){
   echo -e $$ $@ | logger -st "($(basename $0))"
}
#=======================================Main============================================================

Say "Martineau NAT customisation Starting.... "[$@]

# Has services-stop created 'Shutdown' semaphore?
if [ -e "/tmp/SHUTDOWNINPROGRESS" ]; then
   Say "**WARNING: Shutdown in progress: '/tmp/SHUTDOWNINPROGRESS' skipping processing!"
   exit
fi

# With DUAL-WAN and TrendMicro ?, this event gets triggered twice!!!
# Prevent nat-start script from running twice at boot up
LOCKFILE="/tmp/$(basename $0)-flock"
FD=205
eval exec "$FD>$LOCKFILE"
flock -n $FD || { Say "Martineau NAT customisation ALREADY running...ABORTing"; exit; }

Say "Paused for 10 secs"
sleep 10      # Never hurts for nat-start!!!

###=====> Insert custom nat-start code here <=====###

# Release the sempahore lock
flock -u $FD

Say "Martineau NAT customisation complete."

 

[eibgrad]

Something isn't quite right here.

If the remote OpenVPN client of the Android phone is able to get established w/ your OpenVPN server, and gets an IP in the 10.8.0.x network, the fact the target of that remote access is also using the OpenVPN client of that same router (connected to PIA) as its default gateway should be irrelevant. The only time you should have a conflict is when the reply packets are dependent on the default gateway, which has been changed to the PIA gateway. But that's not the issue here. The OpenVPN client of the Android phone doesn't have a public IP!! It's established on the tun21 network interface of the OpenVPN server w/ an IP in the 10.8.0.x network. So the router is fully capable of routing that IP back and forth between the local network interface (br0) and the OpenVPN server's tunnel (10.8.0.x).

IOW, something else is amiss here.

What typically requires marking packets is when you need remote access over the WAN and the client has a ***public IP***!!! It's that public IP that requires routing via the default gateway, which as I said, has been changed to the OpenVPN client on the router (PIA). But again, that's not the case here. The Android client is NOT seen by the router as having a public IP, but rather a private IP in the 10.8.0.x network. So it should be working w/o the need for all that marking of packets. Not unless the description we've been given so far is wrong.

P.S. @wiz was essentially alluding to the same thing, and recommended a static route. But even that shouldn't be necessary when the primary router is hosting the OpenVPN server. It obviously already knows about that network interface (tun21) and network (10.8.0.x), and is the default gateway for your network.

 

[eibgrad]

Just had another thought.

I'm far less familiar w/ policy based routing using Merlin than I am w/ dd-wrt and tomato. But I know on dd-wrt and tomato that each make the same mistake of *only* placing the OpenVPN client (PIA in your case) as the default gateway in the alternate routing table (in the case of Merlin, I assume that's table 254), and I suspect Merlin is doing the same.

ip route show table 254

If that's the case, and you have an ip rule that places *all* devices on 192.168.1.0/24 network on the VPN, and that rule has precedence over the exception for the Desktop (192.168.1.10), then any 192.168.1.0/24 device will be pointing to table 254 and NOT have the routing information for the 10.8.0.x network!

ip rule show

IOW, I *think* the core problem here is having allowed 192.168.1.0/24 to be routed over the VPN and *hoping* the additional rule that makes an exception for the Desktop @ 192.168.1.10 will take precedence. I suspect it's NOT.

What probably would work better is to have NO OVERLAP when defining your rules. IOW, when defining a rule for those source IPs that need to be routed over the VPN, do NOT include 192.168.1.10, even it's implicit (192.168.1.0/24). I believe that's where you messed up.

 

[madfusker]

Maybe I can clarify. On my router I run PIA, and I send all traffic through the VPN as I don't want my ISP selling my traffic data. There are a couple exceptions as Netflix devices that are blocked on VPN, and also my work computer that works so much better if not on the VPN due to all their spyware that complains when it cannot phone home. So most everything is VPN through PIA.

Secondly, I want a secure way to access my home network and don't like the idea of teamviewer type apps that get hacked all the time, so the solution is to connect with my own VPN network and use RDP to see my computers. Here I use openVPN to "get into my network" securely so I can access my machines on my own terms and enc keys.

The original problem was that when I connect via openVPN, I could only access machines that were not on the PIA VPN and excluded with the /24. So my tunnel to my home only got me on the excluded network like my Netflix devices, but not to my main computers. If I am inside my house locally however, and on any machine excluded or not sitting at my desk at home, I can get to any machine I wanted to via RDP whether it's on PIA or excluded. So something about OpenVPN wasn't quite putting me "on my network" as if I was at home, but rather somewhere on the outside of the PIA VPN, but still on the router in the excluded network.

IOW, I *think* the core problem here is having allowed 192.168.1.0/24 to be routed over the VPN and
 *hoping* the additional rule that makes an exception for the Desktop @ 192.168.1.10 will take precedence. I suspect it's NOT.

What probably would work better is to have NO OVERLAP when defining your rules. IOW, when defining a rule for those source IPs
 that need to be routed over the VPN, do NOT include 192.168.1.10, even it's implicit (192.168.1.0/24). I believe that's where you messed up.

The 192.168.1.0/24 rule allows me to ensure that any machine plugged into my network or connects via wifi will go over the VPN. This works so much better with kids and kid friends that use my network when at my house. But until Martineau helped out, I wasn't able to hit those other machines at all. It might not be "right", but until someone can suggest a better setup guide, it's all I have that actually works for the use case above.

 

[madfusker]

Here is my nat-start script template... see if it solves your @boot run-time issues

Rebooted twice and everything is there! Thanks for the magic code!!!

 

[Martineau]

The 192.168.1.0/24 rule allows me to ensure that any machine plugged into my network or connects via wifi will go over the VPN. This works so much better with kids and kid friends that use my network when at my house. But until Martineau helped out, I wasn't able to hit those other machines at all.

It might not be "right", but until someone can suggest a better setup guide, it's all I have that actually works for the use case above.

You have not "messed up"

Whilst not immediately intuitive on the GUI (since most users only wish to route selected IPs via the VPN) , explicitly using the full LAN subnet 192.168.1.0/24 VPN rule is perfectly valid (primarily to allow use of the VPN Client 'kill' switch) but it effectively inverts the (default) meaning of the VPN Client entries - mandating explicit WAN entries as exceptions.

P.S. My implementation of Selective Port (or MAC/IPSET etc.) routing might not be "right", but until someone can suggest/implement a better method...…