After replacing my Dylink router with Pfsense I can no longer RDP to my Windows
-
Hi,
After replacing my D-Link router with pfSense I can no longer RDP to my Windows 2008R2 Server.
The following are the details:
My pfSence Box has two NICs: a one port Intel pro NIC which pfSense see as em0 and a 2 Port PCexpress Gigabit NIC from StarTech which pfSense see as re1 and re2.
I set up em0 as the WAN port using DHCP. It is connected to my Cable Modem.
I set up re1 as my LAN port with a static IP 192.168.1.3. It is connected to my 8 port (not managed) Switch.
Also connected to the Switch are a Windows 2008R2 Server that acts as a DC and Hyper-V server and 3 Workstations. The server also provides DHCP and DNS services to the LAN. The DHCP excluded range is 192.168.1 to 100.
Currently on the WAN port pfSense is picking up an IP address from my ISP. NAT is working correctly and the Sever and PCs have internet connectivity.
I set up Port forwarding following the "How can I forward ports with pfSense"
I set up a NAT rule to forward WAN traffic using TCP protocol that uses MS RDP (port 3389) to my Servers Static IP address and pfSense created a corresponding Firewall rule to allow this this traffic to pass.
When I try to establish an RDP connection to my server from a Laptop using my 3G Hot spot I get an error message that "RDP can't connect to remote computer for one of these reasons …" None of the reasons are applicable. I have no issues establishing an RDP connection to the Server from a PC on the LAN. Before switching from D-Link to pfSense I had no issues connecting to my Server via RDP from remote locations via my 3G Hotspot and since swiching I did not change the Sever / Domain set up.
To try and debug this issue In the Firewall rule I enabled logging "packets that are handled by this rule".
In System Logs I can see a Green Icon next to the lines showing the RDP (TCP: S) connection attempt. When I Right Click the Green Icon I get a message that sais:
The rule that triggered this action is:
@62 pass in log on em0 replay-to (em0 99.226.x.x) inet proto tcp any to 192.168.1.11 port = 3389 flags S/SA keep stable "USER_RULE:NAT RDP to SVR1"
When I check the States table I can not see a transaction coreponding to the RDP conection attempet.
Your help in debugging this issue would be much appreciated
Thank You
-
You need TCP+UDP for RDP.
-
Try forwarding both TCP and UDP.
Also, just to be sure - Make sure pfsense WAN interface is showing a public IP - not private.
Also try rebooting pfsense after you forward both TCP and udp apply the rule.
-
Damn that guy can type fast….
-
Thank you Guy - will try and get back to you soon with outcome.
-
Hi Guys,
I changed TCP to TCP/UDP and rebooted pfSense. Same outcome.
The WAN port is picking up a Public IP and the RDP request is visible in the pfSense Log with a green triangle next to it … but I can not trace it to the State Table.
Any ideas?
Thank you
-
Try it from something other than a cell based connection.
-
Filtering Diagnostics > States on :3389 while attempting to connect should certainly show something.
I know you state it worked with the d-link, but are you sure the target server has pfSense as its default gateway? Are you sure it's not a software firewall issue on the target server?
-
Hi Derelict
Thank you for pointing me in the right direction.
I stated that I did not make any changes on my network and obviously I had to make one simple but very important change.
D-Link was on IP 192.168.1.1 and pfSense is on 192.168.1.3. On the Server the Gateway was 192.168.1.1. The Workstation that I use I have a static IP. When I connected pfSense I changed the gateway to point to 192.168.1.3. I intended to go and make the change on the Server. You reminded me to do just that.
Changed the Gateway on the Server and the RDP connection works!
A beginner’s mistake is fixed.
Thank you again,
-
-
You can see what's being use like this:
(UDP being used since RDP 8.0 - W7 with KB2592687 and any later versions. It should fallback to TCP but someone @M$ obviously finally realized that TCP sucks for RDP over WAN…)
-
Ill give it a try… I find other solutions for remoting in have always been a little better. Id like the MS version to be similar in performance.
:)
-
Yeah - over a long haul, having that UDP port open SHOULD knock off alot of laggyness.
I use UDP VPN myself. I'm not a big fan of opening ports on the wan for RDP directly.
