Cannot use remote desktop? [SOLVED!]
-
Hello, I just recently got pfsense going in my house…..i am having a little problem, i have a server at a remote location i must be able to connect to over windows remote desktop, the remote server is running windows remote desktop on an unconventional port....lets say for ex 4537....now i have two other people who claim its working just fine for them elsewhere and if i bypass pfsense completely it works for me and was working before hand so im gonna blame pfsense.....sometimes if i spam it enough in the RDC window it well give me the login dialog but cant go any further....does anyone got any idea what could be causing this? I thought maybe if i setup static ports as instructed here: https://doc.pfsense.org/index.php/Static_Port it would fix it....but some of those instructions are outdated now...so any help would be appreciated,
-
Is logging of default firewall rules enabled? Anything in the firewall log?
Is the remote IP address a bogon or private? Is the pfSense WAN a bogon or private?
You might try, temporarily for troubleshooting only, disabling all the firewall rules that have a drop action (wan and lan).
-
Are you using a VPN of some sort to get across to the remote site? If so, is there some issue with maximum packet size that will be transported successfully through the tunnel?
Try some pings with increasing packet sizes. -
No i am not using a VPN to get across the remote site, the server on the remote site does vpn into my network here and i can remote it "locally" fine but i need to be able to remote it externally too sometimes, this is necessary…in my logs there is nothing about it
-
What are you lan firewall rules?
-
-
However that remote server VPN's in, before the general rule pushing everything oit WAN_LOAD, you will need to have an ordinary pass rule on LAN for traffic originating on LAN and going to that server. Otherwise when you initiate anything from LAN that general rule policy routes it directly out WAN_LOAD (to the ordinary internet).
-
yes but its not the lan side im having trouble remoting it on…..when it is successfully connected to the network i can remote it just fine over lan but when doing maintenance to it its not reliable to use remote desktop via lan because there can be disconnected so its better just to connect over the internet....there is no issue connecting to the server via remote desktop over lan...
-
It was pfsense, i figured it out…. anyone else who ever has this issue LISTEN UP!
You need to change your outbound NAT to (Under Firewall>Nat>Outbound Tab) to
"Hybrid Outbound NAT rule generation
(Automatic Outbound NAT + rules below)"Then make a rule with the following specified
Disabled: Unchecked
Do not NAT: Unchecked
Interface: WAN
Protocol: anySource:
Type: Network
Address: <your local="" sub="" net="">Source Port: Leave Blank For AnyDestination:
Not: Unchecked
Type: any
Address: N/A (Not Applicable)
Source Port: 3389 (Or whatever port isn't working for you outbound)Translation:
Address: Interface Address
Port: N/A
Static Port: CheckedNo XMLRPC Sync: Unchecked
Description: Put in the name of the service running on this port (HTTP, RDP,ETC...)
Step 2:
Go to Firewall> Rules> "LAN" Tab
Click add rule and set the following
Action: Pass
Disabled: Unchecked
Interface: LAN
TCP/IP Version: IPV4 (Unless you are using IPV6 Which is unlikely)
Protocol: TCP/UDP
Source:
Not: Unchecked
Type: LAN net
Address: N/ASource Port Range: any
Destination:
Not: Unchecked
Type: any
Address: N/A (Not Applicable)Destination Port Range Port: 3389 (Or whatever port isn't working for you outbound)
LOG: I left mine unchecked but you can check it if you wish
Description: Service on that port
Scroll down hit save and apply. you should be all set. :)</your>
-
Source Port: 3389 (Or whatever port isn't working for you outbound)
Static Port: CheckedNonsense… RDP does not use a source port of 3389..
So not sure what you think your fixed did, but was not your problem.. You do not need a static port to rdp..
I rdp outbound of pfsense all the time and don't have to do anything special.. Is your rdp using tcp or udp? rdp can be udp now..
edit
Here is a place you can test oubound rdp from your network.http://help.k2.com/kb001279
They have testrdp.rdp you can download - and see attached it connects just fine.. And I don't have anything special in outbound nats or any rules at all that are special.. Other than the default lan rule that allows traffic out any any.
-
Same here. Outbound RDP no problem. Inbound requires NAT + firewall rule. It just works.
-
This solution needs a youtube video and accompanying blog walkthrough so it can be authoritatively cited again and again and again for years to come.
-
Source Port: 3389 (Or whatever port isn't working for you outbound)
Static Port: CheckedNonsense… RDP does not use a source port of 3389..
So not sure what you think your fixed did, but was not your problem.. You do not need a static port to rdp..
I rdp outbound of pfsense all the time and don't have to do anything special.. Is your rdp using tcp or udp? rdp can be udp now..
edit
Here is a place you can test oubound rdp from your network.http://help.k2.com/kb001279
They have testrdp.rdp you can download - and see attached it connects just fine.. And I don't have anything special in outbound nats or any rules at all that are special.. Other than the default lan rule that allows traffic out any any.
Well how come when i undo all that stuff i did to make it work….it stops working again hmmm?obviously i need it if that is the case...Also need i remind people i have two WANS and am not using the conventional Remote Dektop port...i did howver verify just now all that is needed is an outbound firwall rule before the DUAL wan gateway firewall rule.
-
The firewall rule you added does nothing at all. The default LAN rule is already doing what that does.
The outbound NAT you added translates the source port of everything leaving your network to port 3389, which is absurd and will break things in a lot of circumstances, especially where you have multiple clients connecting out to the same remote server. There are possibly reasons that using a certain smaller range of source ports rather than the default 1024-65535 will work. But making the source port of everything leaving your network static at 3389 isn't good in any circumstance.
The symptom you started with is almost certainly a path MTU issue of some sort, that's exactly what will happen when large packets are getting dropped somewhere in transit.
If you want to muck with outbound NAT, set it to static port, not translated to port 3389. See what that does. There is no reason static port is required in any circumstance for RDP, but letting the clients use their smaller ephemeral port range might be telling, and it's a lot more sane than deciding 3389 is a good source port for everything.
A much better answer is to get packet captures from the machine you're connecting to, and on your WAN where the traffic is egressing on your side, and compare what's actually happening. There is some explanation outside of doing insane things with outbound NAT.
-
It clearly does seeing as without it it doesnt work AT ALL
-
The firewall rule is doing nothing at all if you have the stock default LAN rule in place. The NAT change might be impacting something, but translating the source port to 3389 on all traffic leaving your network is insane. That'd be a sign there is something else that needs to be investigated.
But hey, if you're happy with it, it's perfectly apt for the "nut" part of your username. :)
-
I don't care what port the remote rdp is listening on.. Be 3389, 41441, 1234, etc. etc..
What you described is just nonsense..
Doesn't matter if you had a 100 wan connections… Now if you want to route traffic out to this remote desk top via specific wan, ok do that. Do you have an issue with the return traffic coming back to a different wan interface?
You do not need to use a static port for your napt for the remote desktop protocol to work! Nor do you need to change your outbound nat to use anything specific as source. Period Unless there is some rule past pfsense that is blocking traffic based on source port??
Do you understand how napt works in pfsense?? I would suggest you take a look at your state table for the dest port and source ports that are used, and how pfsense changes that on the public side.. And exactly happens with a static port.. Why would you think that a requirement for rdp through a nat??
Why don't you leave your outbound nat as automatic, there is RARELY a need to mess with those, you will prob need to add outbound nats if your doing something with client vpn connection, etc.. But with just normal wan, and road warrior vpn connections into you auto nat works just fine.
What specific version of rdp are you using? I would suggest you sniff on your want that the traffic is suppose to go out, and validate you get a answer back..
You say your using multiple wan, how exactly do you have that setup... Why don't test just using 1 wan connection for your rdp connection... My guess is something in that setup is your problem.
"sometimes if i spam it enough in the RDC window it well give me the login dialog but cant go any further"
Here is the thing.. If it was a firewall rule blocking your access.. You could spam it all you wanted til doomsday its not going to allow you out or work, if the rule says not too.. What would be the point of a firewall that sometimes allows traffic or sometimes blocks traffic??? If your saying it sometimes starts to work, then that points to something intermittent or something that changes... Like maybe the return traffic sometimes coming back to the same wan connection your traffic went out on.. But normally coming back on the wrong wan, so your states are not there and pfsense would block that traffic.
-
"You do not need to use a static port for your napt for the remote desktop protocol to work! Nor do you need to change your outbound nat to use anything specific as source. Period Unless there is some rule past pfsense that is blocking traffic based on source port??
You can stop bitching not i got rid of the static port nat rule and left the firewall rule and it still works
-
@networknut Wow! I have been struggling with this for months! This makes no sense but it bloody works. I had the same problem with OPNSense as well and logically the same rules should fix the problem in that as well.
