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

Problem with ms rdp

Scheduled Pinned Locked Moved NAT
6 Posts 4 Posters 3.0k 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.
  • T
    tommie
    last edited by Jan 27, 2007, 10:53 PM

    Hi,

    I am unable to set up a nat rule for ms rdp.  However my other forwards are working.  It looks a problem in the interface.

    I have setup a nat rule to redirect 3389 to my internal ip… however i get:

    tommie@justin:~$ telnet myhostname.be 3389
    Trying xxx.xxx.xxx.xxx...
    telnet: Unable to connect to remote host: No route to host

    if i change the source port to 3390 in the nat rule and leave the rest like it was, I get:
    tommie@justin:~$ telnet myhostname.be 3390
    Trying xxx.xxx.xxx.xxx...
    Connected to myhostname.be.
    Escape character is '^]'.

    Is there a solution available or am i able to change it in the config file directly?

    Regards
    tommie

    1 Reply Last reply Reply Quote 0
    • H
      hoba
      last edited by Jan 27, 2007, 10:58 PM

      Try configuring miniupnp. This way the msn messenger can dynamically open needed ports itself. It's included in recent snapshots (http://snapshots.pfsense.com/FreeBSD6/RELENG_1/) and can be found in the services menu.

      1 Reply Last reply Reply Quote 0
      • T
        tommie
        last edited by Jan 28, 2007, 9:15 AM Jan 28, 2007, 9:11 AM

        I'm sorry but I don't see what this has to do with a remote desktop connection?  It is only one port it should use…

        mmm strange i just changed the port back from 3390 to 3389 and now it works :S  I am going crazy :-)

        1 Reply Last reply Reply Quote 0
        • S
          sullrich
          last edited by Jan 28, 2007, 9:22 AM

          @tommie:

          I'm sorry but I don't see what this has to do with a remote desktop connection?  It is only one port it should use…

          mmm strange i just changed the port back from 3390 to 3389 and now it works :S  I am going crazy :-)

          You should not need a source port in the rule…  The description says that its only needed 1% of the time and this is not one of them.

          1 Reply Last reply Reply Quote 0
          • H
            hoba
            last edited by Jan 28, 2007, 11:55 AM

            @tommie:

            I'm sorry but I don't see what this has to do with a remote desktop connection?  It is only one port it should use…

            I somehow misread something, sorry.

            1 Reply Last reply Reply Quote 0
            • Y
              yoda715
              last edited by Jan 28, 2007, 9:59 PM

              Your description of your problem is not totally clear, but here is how the NAT should look for RDP:

              If  Proto  Ext. port range  NAT IP  Int. port range 
              WAN TCP 3389 (MS RDP)   Internal PC    3389 (MS RDP)

              The firewall rule will then look something like this:
              Proto    Source      Src Port      Destination IP    Dst Port
              TCP  Any                *  Internal PC        3389 (MS RDP)

              If you chance the NAT Internal Port Range, you have to modify the Firewall rule Dst Port to reflect the same change. In other words your Int Port Range, NAT IP in your NAT and the DstIP, Dst Port in the firewall rule must always match.

              The only other problem that I can see is that the machine running terminal server is listening on 3390 instead of 3389. Do a google search on how to change this back to 3389 if you need to.

              1 Reply Last reply Reply Quote 0
              6 out of 6
              • First post
                6/6
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                This community forum collects and processes your personal information.
                consent.not_received