1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

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

Discussion in 'Asuswrt-Merlin' started by madfusker, Aug 11, 2018.

  1. madfusker

    madfusker Regular Contributor

    Joined:
    Jul 20, 2014
    Messages:
    118
    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. :/
     
    Last edited: Aug 11, 2018
  2. Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!
  3. madfusker

    madfusker Regular Contributor

    Joined:
    Jul 20, 2014
    Messages:
    118
    Here is more info:
    [email protected]:/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
    [email protected]:/tmp/home/root#​
     

    Attached Files:

    • 1.jpg
      1.jpg
      File size:
      72.9 KB
      Views:
      27
    • 2.jpg
      2.jpg
      File size:
      76.8 KB
      Views:
      25
    • 3.jpg
      3.jpg
      File size:
      63.9 KB
      Views:
      28
  4. wiz

    wiz Regular Contributor

    Joined:
    Feb 15, 2013
    Messages:
    122
    Location:
    the Netherlands
    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.
     
  5. Martineau

    Martineau Very Senior Member

    Joined:
    Jul 8, 2012
    Messages:
    1,646
    Location:
    UK
    Allow WAN RDP access to a LAN PC that is routed via OpenVPN Client
     
    madfusker likes this.
  6. madfusker

    madfusker Regular Contributor

    Joined:
    Jul 20, 2014
    Messages:
    118
    @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:
    Code:
    #!/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:
    Code:
    [email protected]:/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:
    Code:
    [email protected]:/tmp# /jffs/scripts/nat-start
    [email protected]:/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?
     
    Last edited: Aug 12, 2018
  7. madfusker

    madfusker Regular Contributor

    Joined:
    Jul 20, 2014
    Messages:
    118
    Just for fun I tried to insert a "sleep 10" into the script right after all the -D lines, but before the -A lines.

    Code:
    [email protected]:/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
    [email protected]:/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?

    Code:
    [email protected]:/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
    [email protected]:/tmp/home/root#
    
     
    Last edited: Aug 12, 2018
  8. madfusker

    madfusker Regular Contributor

    Joined:
    Jul 20, 2014
    Messages:
    118
    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.
     
  9. Martineau

    Martineau Very Senior Member

    Joined:
    Jul 8, 2012
    Messages:
    1,646
    Location:
    UK
    Here is my nat-start script template... see if it solves your @boot run-time issues
    Code:
    #!/bin/sh
    
    Say(){
       echo -e $$ [email protected] | logger -st "($(basename $0))"
    }
    #=======================================Main============================================================
    
    Say "Martineau NAT customisation Starting.... "[[email protected]]
    
    # 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."
     
    Last edited: Aug 13, 2018 at 7:15 AM
    madfusker likes this.
  10. eibgrad

    eibgrad Occasional Visitor

    Joined:
    Feb 20, 2017
    Messages:
    34
    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.
     
    Last edited: Aug 12, 2018
  11. eibgrad

    eibgrad Occasional Visitor

    Joined:
    Feb 20, 2017
    Messages:
    34
    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.

    Code:
    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!

    Code:
    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.
     
  12. madfusker

    madfusker Regular Contributor

    Joined:
    Jul 20, 2014
    Messages:
    118
    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.

    Code:
    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.
     
  13. madfusker

    madfusker Regular Contributor

    Joined:
    Jul 20, 2014
    Messages:
    118
    Rebooted twice and everything is there! Thanks for the magic code!!!
     
    Martineau likes this.
  14. Martineau

    Martineau Very Senior Member

    Joined:
    Jul 8, 2012
    Messages:
    1,646
    Location:
    UK
    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...… :D
     
    Last edited: Aug 13, 2018 at 7:11 AM
    evh909 and madfusker like this.
Please support SNBForums! Just click on this link before you buy something from Amazon and we'll get a small commission on anything you buy. Thanks!