Microsoft Remote desktop on windows 10
-
hello all,
I am hoping some one here has this working and can probably help me out.
Remote desktop was all working fine (from external network, WAN) before setting up Pfsense. now with pfsense I am unable to connect to my pc via remote desktop.
below are the current configurations set of the pfsense router.
1. remote desktop works well within the same network and I have no issues.
2. I have a dynamic DNS setup for my pc, and have the client up and running
3 in NAT I have the rule setup to forward any WAN request coming in with a destination port 3389 to forward it to my local ip address 192.168.1.139 and port 3389
4. in firewall Pfsense automatically creates a firewall rule for the NAT I have in (3)
5. I have openVPN setup, but for the current scenario I have openVPN diabled for my PC.on the remote desktop app, pcname is the local ipaddress of my pc 192.168.1.139:3389
username is the my pc username
gateway is the ddns name for the pcThis used to work well on my asus router before I changed to running pfsense.
ashish
![Nat RULE.jpg](/public/imported_attachments/1/Nat RULE.jpg)
![Nat RULE.jpg_thumb](/public/imported_attachments/1/Nat RULE.jpg_thumb)
![firewall rule.jpg](/public/imported_attachments/1/firewall rule.jpg)
![firewall rule.jpg_thumb](/public/imported_attachments/1/firewall rule.jpg_thumb) -
you sure your not trying to use rdp over udp? you lave it limited to tcp. Also the windows firewall is most likely out of the box going to block access to remote desktop from IP other than its local network.
Its really really a bad idea to open rdp to the public internet, you should vpn in if you want to remote desktop your machines
-
hi john,
yes I understand the risks of opening up to the public, but first I am trying to make it work. I had the NAT rule set to just TCP, but even with TCP/UDP I haven't been successful. in Windows 10 I have remote access to the pc enabled with network level authentication enabled.
ashish
-
ok I figured out to remote desktop into the LAN from WAN, everything was correct, except the VPN was turned ON, even though I put only a specific IP address on LAN associated to the VPN, and everything else i.e. LNA-net to use WAN.
what is weird is, Iplocation .net gives me the WAN address when checked from the PC that is excluded from the VPN filter (which is correct)
but when i open the portcheck tool website it shows me the vpn connected ip address from the same PC ???? how is that possible?and when i port check it shows 3389 is closed for the NAT rule for openVPN ip address, I have a screen shot of the VPN NAT rule attached.
anything wrong with the way the port forwarding is setup?? I am unable to free the port
ashish
![Nat RULE.jpg](/public/imported_attachments/1/Nat RULE.jpg)
![Nat RULE.jpg_thumb](/public/imported_attachments/1/Nat RULE.jpg_thumb) -
I am confused why you need Rule#2 and Rule#3 in your screenshot. When are there going to be packets entering your pfSense router via the PIAVPN or PIAVPN2 interface with a "destination" of your WAN interface IP? Seems like you could delete those.
-
Yeah those are useless..
-
yes correct, those rules do nothing. I deleted them. but I still have trouble accessing windows 10 using remote desktop when I am connected through a VPN.
-
It sounds like you have the VPN only semi-set up and are just trying to connect to your WAN IP (linked to a Dyndns) directly which is port forwarded (NAT) to an internal IP. Is that right? What IP are you entering into your RDP client? There could be any number of links along the way blocking tcp3389 - that could be for security reasons. Run a tcpdump on your pfSense during a connection attempt and try to see if the packets are reaching the interfaces that you expect.
-
…connected through a VPN.
You are on a different ip range than your RDP host, right?
When switching from your ASUS router you created a new network which your Win10 PC most probably detected as new. Did you set it to private?
You need to create rules to allow inbound RDP attempts on your Win10 "firewall" from local as well as non-local clients.