Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    What port does MS Remote Desktop send data to?

    Scheduled Pinned Locked Moved Off-Topic & Non-Support Discussion
    11 Posts 4 Posters 2.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      pfBug
      last edited by

      Subject says it all. I know MS RDP listens to port 3389 for connections. Does it also send the RDP data through port 3389? If so, would changing the default port of MS RDP help me establish a remote connection on a network that is blocking port 3389? The network I would connect from has a limited number of ports open. nMap reported back the following open ports:

      PORT    STATE  SERVICE
      113/tcp  closed ident
      443/tcp  open  https
      541/tcp  open  uucp-rlogin
      8000/tcp open  http-alt
      8009/tcp open  ajp13

      I'm thinking about using port 443 for MS RDP, though I have no idea if this will work.

      1 Reply Last reply Reply Quote 0
      • K
        kejianshi
        last edited by

        Use openvpn.  Problem solved.
        Try UDP first and then if thats not good switch to TCP on port 443 for the vpn.

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by

          What exactly have you scanned with nmap to generate that list?

          1 Reply Last reply Reply Quote 0
          • K
            kejianshi
            last edited by

            If you were scanning the public IP from some other computer/IP, this would indicate you have services running on all those ports or at least that the ports were opened/forwarded.

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              Exactly. It seems unlikely, but not impossible, that the network you're on doesn't allow out traffic on port 80. Forced local proxy perhaps?

              Steve

              1 Reply Last reply Reply Quote 0
              • P
                pfBug
                last edited by

                @stephenw10:

                What exactly have you scanned with nmap to generate that list?

                I scanned the public IP address of the network I will be using to, hopefully, connect to my home LAN, via MS RDP or OpenVPN. The command I used to generate that list is as follows:

                sudo nmap -p 1-65535 PUB.LIC.IP.ADD

                So, I think you're correct in your observation, port 80 doesn't allow traffic. What's really got me stumped now is that I was able to RDP into a client on a different network. When I use the command "sudo nmap -p 3389 PUB.LIC.IP.ADD" it reports back:

                Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
                Nmap done: 1 IP address (0 hosts up) scanned in 3.35 seconds

                How can I RDP into a client on another network if my LAN is blocking port 3389?

                1 Reply Last reply Reply Quote 0
                • KOMK
                  KOM
                  last edited by

                  How can I RDP into a client on another network if my LAN is blocking port 3389?

                  Configure the RDP server to listen on a different port and then connect via that port.

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    Hmm, I think you're testing the wrong thing or doing it the wrong way.

                    I scanned the public IP address of the network I will be using to, hopefully, connect to my home LAN

                    So this is the WAN address of the network you will be on when you connect back to your home public IP. Where were you scanning from? It doesn't actually matter. Port 3389 is shown as blocked in your scan because that network doesn't have an RDP server accepting connections from the internet. That doesn't mean that it won't allow out traffic on 3389 once you're on it.

                    Steve

                    1 Reply Last reply Reply Quote 0
                    • P
                      pfBug
                      last edited by

                      @KOM:

                      How can I RDP into a client on another network if my LAN is blocking port 3389?

                      Configure the RDP server to listen on a different port and then connect via that port.

                      Sorry. I didn't realize that question could be read two different ways. What I meant to ask was how is it possible that I am able to RDP into a client on another network if my LAN is blocking port 3389? I thought that if a port was blocked it stopped sending and receiving data, and since my LAN is blocking 3389 well, you probably see what I'm saying. Of course, maybe my assumption was wrong and a blocked port on a LAN only stops data from coming in, but not being sent?

                      @stephenw10:

                      Hmm, I think you're testing the wrong thing or doing it the wrong way.

                      I scanned the public IP address of the network I will be using to, hopefully, connect to my home LAN

                      So this is the WAN address of the network you will be on when you connect back to your home public IP. Where were you scanning from? It doesn't actually matter. Port 3389 is shown as blocked in your scan because that network doesn't have an RDP server accepting connections from the internet. That doesn't mean that it won't allow out traffic on 3389 once you're on it.

                      Steve

                      That's right, Steve. So, as I just said above, I always assumed a blocked port would stop all traffic on that port. But it does make since that if I am on that network I could send traffic out. I don't suppose there is a way to block out going traffic on a specific port? I'd like to know in case I ever need to change ports.

                      Anyway, RDP is working fine as of now. It's not my ideal solution, as I'm not able to copy files from my home PC to the one I'm on now (a Macbook Air running Ubuntu). That's probably some issue with my RDP client software. I am curious though, is MS RDP encrypted?

                      1 Reply Last reply Reply Quote 0
                      • K
                        kejianshi
                        last edited by

                        VPN would allow you to grab the files you need.  So would sftp.  VPN would also take care of your security issues.

                        The security of RDP directly over open internet is debatable.

                        I only do it over VPN.

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          @pfBug:

                          I don't suppose there is a way to block out going traffic on a specific port?

                          Sure there is. If you're using pfSense as a firewall you would just add a block rule of the LAN interface (or omit any allow rule).

                          However I think the source of your initial confusion here is that you have interpreted the the results of your nmap scan incorrectly. The fact that port 3389 is shown as blocked does not mean that your loacl network is preventing that traffic leaving but rather the remote network is preventing it from entering. It also does not mean that the remote network restricts outgoing traffic at all. It is showing only the restrictions on incoming traffic.

                          Steve

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.