Posted: Mon Mar 08, 2021 21:50 Post subject: Using RDP on VPN
My goal is to use Remote Desktop Protocol (RDP) to remotely log into my "workhorse" laptop (connected to my DD-WRT router at home) via a VPN tunnel.
The workhorse laptop is connected to my router running DD-WRT r45948, which is hosting both an OpenVPN server and Wireguard tunnel. The laptop has two static IP leases on my home network (192.168.1.104 for LAN and 192.168.1.102 for wireless). RDP is enabled, the laptop firewall has a rule to allow connection via the standard RDP port (3389). I am able to connect to it via RDP from a second laptop, provided that both laptops are connected to the DD-WRT router. What I am not able to do is connect to it via RDP when the second or "remote" laptop is on a different wifi network and connected to the DD-WRT network via either OpenVPN or Wireguard (and this is the goal).
Here's what I can do via the laptop connected to the VPN (same for both OpenVPN and Wireguard connections):
-- I can view 192.168.1.1 (dd-wrt router configuration), as if I were on the local network
-- I can use "telnet 192.168.1.104 3389" to open a connection to the workhorse, which stays open for several minutes (maybe indefinitely) unless I kill it
--I can connect via RDP briefly: I enter the IP (192.168.1.104) in the RDP window, enter my password when the window appears, the local session on the workhorse laptop closes and an RDP window opens on the remote laptop. The RDP window remains blank, however, and the session disconnects with the error: "Your remote Desktop Services session has ended. Another user connected to the remote computer, so your connection was lost. Try connecting again, or contact your network administrator or technical support group."
Naturally, another user has not connected, but I am including this because it might be an important clue. It seems like something about the way the router is bringing together VPN clients and locally-connected clients is off or incompatible with RDP. Some other things I checked:
OpenVPN, Wireguard and the local subnets are all different (although I did try setting Wireguard up on the 192.168.1.0/24 subnet---this worked the same as far as connecting the Wireguard peers and getting me the results above, but it didn't solve my problem).
Both OpenVPN and Wireguard are in tunnel mode (hopefully this isn't my issue, as I really need the performance of Wireguard here, and would rather not expose an RDP port to the world via port forwarding if I can avoid it).
By default, Windows will NOT allow access between different *private* IP networks. Not unless you specifically enable that access in the firewall for the client's network, whether it's another local private network, or the VPN client's tunnel network.
P.S. If that is the problem here, an alternative to updating all the Windows firewalls (which may be impractical for some users) is to nat the inbound traffic from the OpenVPN server's tunnel network over the private network (br0).
Code:
iptables -t nat -I POSTROUTING -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -o br0 -j SNAT --to $(nvram get lan_ipaddr)
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Tue Mar 09, 2021 11:56 Post subject:
As @eibgrad described I allow the OpenVPN servers subnet 10.8.0.0 (and if you need the WG subnet) in the windows firewall to get access to my windows clients.
Thanks for the quick responses. I tried all of these solutions, with no luck.
One other thing that has me wondering if it is a network access issue as you both suggest is that RDP is not blocked---it will connect, but the connection drops after 10 seconds with that strange error about another user connecting, and it never shows anything in the RDP window (although it does close the active local session on the target computer, as it should when an RDP session is opened).
Also, I set up my Wireguard tunnel to assign IPs on the same subnet as the target computer (is that legit, by the way? It seems to work OK, but it doesn't solve the RDP connection-dropping problem). Shouldn't having the Wireguard peer on the same subnet have the same effect as adding the NAT rule or modifying the firewall?
So to review:
--if I disable the firewalls on the target computer, I get the same result (connects then drops)
--I also added @eibgrad's NAT rule--same thing
Also, regarding @eibgrad's NAT rule (#1 below), is #2 conflicting with it or making it redundant?
Code:
Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination
1 SNAT all -- 172.27.224.0/24 anywhere to:192.168.1.1
2 MASQUERADE all -- 172.27.224.0/24 anywhere
3 SNAT all -- 192.168.1.0/24 anywhere to:10.0.0.50
4 SNAT all -- 192.168.1.0/24 anywhere to:10.0.0.50
5 RETURN all -- anywhere anywhere PKTTYPE = broadcast
6 MASQUERADE all -- 192.168.1.0/24 192.168.1.0/24
7 RETURN all -- anywhere anywhere PKTTYPE = broadcast
8 MASQUERADE all -- 192.168.1.0/24 192.168.1.0/24
Thoughts? Use TAP instead of TUN? Get a different RDP client? Try different ports? Give up and use port forwarding?
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Tue Mar 09, 2021 16:15 Post subject:
WireGuard just like Openvpn (TUN) is a routed protocol so it needs to be on its own subnet so you always have to have 3 different subnets for the client, the server and the tunnel.
@egc, gotcha---three different subnets is what I originally had. Interestingly, everything (except RDP) seems to work OK with the Wireguard peers assigned to the router's local subnet, but I'll switch it back.
Any other thoughts on why the connection doesn't stick?
Here are those routing tables:
Code:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6288 431K ACCEPT all -- oet1 * 0.0.0.0/0 0.0.0.0/0 state NEW
27708 7101K ACCEPT all -- tun2 * 0.0.0.0/0 0.0.0.0/0
369K 158M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
10319 3812K upnp all -- * * 0.0.0.0/0 0.0.0.0/0
31 1240 lan2wan all -- oet1 * 0.0.0.0/0 0.0.0.0/0
10319 3812K lan2wan all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * vlan2 192.168.1.0/24 0.0.0.0/0 tcp dpt:1723
0 0 ACCEPT 47 -- * vlan2 192.168.1.0/24 0.0.0.0/0
0 0 TRIGGER all -- vlan2 br0 0.0.0.0/0 0.0.0.0/0 TRIGGER type:in match:0 relate:0
10288 3811K trigger_out all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 TRIGGER all -- vlan2 eth0 0.0.0.0/0 0.0.0.0/0 TRIGGER type:in match:0 relate:0
0 0 trigger_out all -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 TRIGGER all -- vlan2 vlan1 0.0.0.0/0 0.0.0.0/0 TRIGGER type:in match:0 relate:0
0 0 trigger_out all -- vlan1 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- vlan1 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 TRIGGER all -- vlan2 wlan0 0.0.0.0/0 0.0.0.0/0 TRIGGER type:in match:0 relate:0
0 0 trigger_out all -- wlan0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- wlan0 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 TRIGGER all -- vlan2 wlan1 0.0.0.0/0 0.0.0.0/0 TRIGGER type:in match:0 relate:0
0 0 trigger_out all -- wlan1 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- wlan1 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 TRIGGER all -- vlan2 oet1 0.0.0.0/0 0.0.0.0/0 TRIGGER type:in match:0 relate:0
31 1240 trigger_out all -- oet1 * 0.0.0.0/0 0.0.0.0/0
10161 3806K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
158 6320 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 3303 packets, 238K bytes)
pkts bytes target prot opt in out source destination
3695 267K MASQUERADE all -- * vlan2 172.27.224.0/24 0.0.0.0/0
12998 3916K SNAT all -- * vlan2 192.168.1.0/24 0.0.0.0/0 to:10.0.0.50
0 0 SNAT all -- * vlan2 192.168.1.0/24 0.0.0.0/0 to:10.0.0.50
0 0 RETURN all -- * oet1 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
8 416 MASQUERADE all -- * oet1 192.168.1.0/24 192.168.1.0/24
0 0 RETURN all -- * br0 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
834 54122 MASQUERADE all -- * br0 192.168.1.0/24 192.168.1.0/24
I'm still messing with this. Not urgent, but I am really curious what the problem is now. I've searched high and low and I find people here and there over the years who have had a similar problem, but no clear solutions.
I tried @eibgrad's route for the Wireguard VPN, too, and I get the same result: RDP connects, but the window stays black and it disconnects after ~20 seconds. Same if I turn the firewalls off (including the firewall on the router). The only thing that works is connecting both computers directly to the LAN.
Joined: 30 Jun 2014 Posts: 61 Location: California
Posted: Sat Mar 13, 2021 23:41 Post subject:
I have been using RDP exactly the way you desire for several years, originally with OpenVPN and now with Wireguard, so don't give up. It is possible.
You are already getting advice from two of the masters (whose posts let me accomplish it), so I don't have much to add, except to suggest it may be a problem with RDP.
RDP server on Windows Home will not allow two connections at the same time. That includes an RDP connection and a normal local user logged on (even as different users). Test if this is your problem by either: (1) trying to RDP into your workhorse from a different machine on your LAN, and/or (2) log all other users off the workhorse and try to RDP over VPN.
Thanks, @gin-n-tonic. I am confident that it's possible. I just think my setup is messed up somehow.
I've done both (1) and (2) as you suggested---I have no problem with RDP when both machines are attached to the LAN / wifi, and I have done this with 3 different laptops. If I have a local session going on the target, it just boots off the local user and connects the RDP user to the same session / windows that were open.
I did try something new recently, which was to put the target machine on the VPN and the RDP client machine on the LAN (the reverse of what I really want to do). This doesn't work at all -- I don't remember the exact error, but it is the same message you get if you put the IP address in wrong. But if the target machine is on the LAN and the client is connecting via VPN, I can connect, but the connection drops in 20 seconds or so (as described in my first post).
Not sure if that is a useful clue, but I would have expected it to work fine both directions.
The workhorse laptop is connected to my router running DD-WRT r45948, which is hosting both an OpenVPN server and Wireguard tunnel. The laptop has two static IP leases on my home network (192.168.1.104 for LAN and 192.168.1.102 for wireless). RDP is enabled, the laptop firewall has a rule to allow connection via the standard RDP port (3389). I am able to connect to it via RDP from a second laptop, provided that both laptops are connected to the DD-WRT router. What I am not able to do is connect to it via RDP when the second or "remote" laptop is on a different wifi network and connected to the DD-WRT network via either OpenVPN or Wireguard (and this is the goal).
Given the lack of progress, let me be perfectly blunt. I can't make heads or tails of the above paragraph. I find it full of ambiguity. I must have read it 30 times by now, and I still can't figure it out. Might be time to draw a diagram of what works and what doesn't, and make it clear where devices are located, which is connected via wire vs. wireless, what is accessing what over the OpenVPN client vs. locally, etc. Sometimes words just aren't enough. Otherwise, I'm at a loss.
Joined: 30 Jun 2014 Posts: 61 Location: California
Posted: Sun Mar 14, 2021 4:34 Post subject:
Well, that might be a clue. Sounds like messages from the client on the VPN are getting through to the target machine on the LAN, however the return signal from the target is not finding its way back to the client. Maybe a routing problem.
EGC's guide suggests disabling CVE-2019-14899 Mitigation (default is on) on the WG & OVPN set up pages. I have this disabled, along with NAT via tunnel.
Or perhaps an MTU problem??? I have explicitly set mine at 1420 for the tunnel. (And 1500 on the Basic Setup page.)
I think these are the only non-default settings I have that might effect RDP.
Thanks, everyone. Good call on the diagram @eibgrad, although it only relevant for posterity at this point, because...
...three cheers for the DD-WRT noob! I started messing with the OpenVPN tunnel MTU as @gin-n-tonic suggested, and dropping it from 1500 to 1400 got it working, at least somewhat. Maybe it was a latency issue? I am going to mess with it some more to see if I can dial it in to make it more usable and see how it goes with Wireguard.