RDP through (open)VPN Problem
-
Hi all,
I am wondering if someone had the same situation and has a hint for me what to do.
Scenario:
- OpenVPN on pfSense Appliance (2.4.5) configured and working.
- Users are connecting from Windows PCs (Windows7,8 10) to openVPN Server using openVPN Client for windows.
- openVPN "LAN" is a seperated subnet. From there I have a natted IP which allows RDP into my Office LAN to my Terminal Server (Windows 2008 R2). And yes I know it is out of everything but I still need to use it for a while.
- It works as expected. User opens VPN connection and opens RDP to the natted IP.
With two of my users I have a problem (one is running Win 10 Pro the other Win 7). They can not connect via RDP to the server.
What did I do:
- I did check FW rules, NAT settings. whatever.
- I did check FW logs and state logs.
- I can not see any difference.
- No FW, Antivirus or whatever on the local PCs.
- When I send the natted IP to another machine in my Office LAN (Windows 10) it works without changing anything on client side.
Any ideas?
thanks and best regards
Dabbelju -
Ok want to make sure we are on the same page here.. When you say natted IP, you mean just the rfc1918 address.. Lets say this 2k8r2 server is 192.168.0.100
So with a remote vpn client connecting to your pfsense vpn server you would have say this
Client (10.0.8.X) -- tunnel network 10.0.8/24 -- pfsense - 192.168.0/24 - server (192.168.0.100)
Couple gotchas with remote vpn... If the remote client is using the same local network as you, say 192.168.0/24 then yeah you could have issues connecting to devices on your 192.168.0 network. For sure if they for example using the same 192.168.0.x address as the server they are trying to talk to..
If you are going to have remote clients coming from all kinds of different networks, say hot spots like starbucks or mcdonalds, their homes, etc. You have no idea what network they might be using where they are at.
So its good practice if your going to support remote vpn users, to try and use as least common rfc1918 network on your side as possible.. 172.27.13/24 for example..
Same goes for your tunnel network.. If you are using 10.0.8/24 which I believe is the default - if your remote users local network is 10.0.8 or something that overlaps say 10/8 which have seen.. Then yes you could have problems with these users connecting. So use as well a non common tunnel network.
Another gotcha is firewall on the server your wanting to rdp too. Does it allow your tunnel network.. Since your saying other devices are working fine. This prob not the case - but it a common mistake made.
RDP can sometimes be finicky on version, using udp or not.. So yeah its possible sometimes for specific clients having issues talking to specific servers depending on the version of rdp client used and settings both on the client or the server.
I would get the specifics of the clients network, look to see what vpn tunnel IP they are getting when they vpn in. What version of rdp client they are using, what are the settings for connection..
You sure your just not running into a license issue - unless you have terminal services installed, only 2 concurrent connections could be made to your server, etc.
What specific error are the clients getting? Can they ping the IP? Do a traceroute and make sure its going through the tunnel for the IP of the server.
-
Thanks for your detailed reply.
yes, I am using RFC1918 addresses and I did make sure that the local IP networks @my clients side are not the same as I use for the tunneling network or any other network inlcuded in my scenario.
Here a bit more details from my end:
IPv4 Tunnel Network: 172.29.112.0/24
OfficeLAN: 10.203.112.0/23"natted IP": virtual IP on pfSense 172.29.112.210. NAT from Port 42168 to internal 10.203.112.122:3389 (2k8 Server). According FW Rule is set up.
My remote clients are employees from our company working from home. All of them have the classic DSL or similar router setup at home.
When VPN connection on client side is up only traffic to 172.29.112.0/24 is routed into the tunnel. Everything else goes out the normal way cause I do not want this traffic in my Network.
I have about 20 clients connected to the openvpn server getting IP adresses from IPv4 Tunnel network. 18 of them can use RDP to 172.29.112.210:42168, 2 can not.
Licensing problem on TS is checked and it is no problem.
Then I started to check local things on the client PCs like FW, Antivirus, whatever. This is not the problem.
The funny thing is: If I do the same thing but with an public IP natted to the internal TS win2k8 without using a VPN tunnel Server it works.
And: If I do the same thing to lets say a Win10 client, it works too.
So the problem must have something to do with RDP over VPN to Win2k8/Win7.
-
@dabbelju007 said in RDP through (open)VPN Problem:
"natted IP": virtual IP on pfSense 172.29.112.210. NAT from Port 42168 to internal 10.203.112.122:3389 (2k8 Server). According FW Rule is set up.
Why would you do that?
They should just access the 10.203.112.122, there is no reason to nat this at all.
-
I do this, because I do not want to route traffic to my 10.203.112.0/23 Network in the tunnel. The next reason is, that the IP of my TS will change in a while. Then I only need to change the NAT rule.
-
Well I would sniff the traffic, also checking there are no conflicting states with that vip and port, etc.
Does traffic hit your vip to that port, does pfsense send it on to 10.203.112.122:3389
-
I did. I took trcaes at pfSense and at the same time at TS.
- If do see the traffic hitting my TS.
- I see the entry in the pfSense FW log (logging for the rule is enabled)
- I see an established connection state in the pfSense logs
- It asks me for Username and Password. If I do enter a wrong combination it rejectes me.
- If I do enter valid credentials is says: "Configuring remote session" and the it takes a while till the error message comes "An error occured".
-
Well that has ZERO to do with pfsense.
-
True. I never said that it has something to do with pfsense. But I found the problem and perhaps it might be interesting for others.
I dig a bit further and I did figure out that it has to do with the MTU Size of the packets in connection with certain providers.
How did I come up with it?
Yesterday I did configure one Notebook here in the office with openVPN and rdp connection. I did use our Guest lan to test it.openVPN => works
RDP => worksToday the Notebook is at home and I have the described problem.
So I did start playing arround with ping MTU size (option -l) and did figure out that I can get a reply with packet size 1471 but not anymore with 1472.
I did use the custom option in openVPN server config and did try it with tun-mtu 1300; and it works!
I will now try to figure out what the best MTU size is.
thanks a lot for your help, always usefull to me!
