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

    Redirect Target Port not working 2.0-RC3

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    8 Posts 3 Posters 3.8k 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.
    • M
      miltimj
      last edited by

      I'm using 2.0-RC3 (i386) built June 28 (and another before that) to try to redirect two different things (VNC and RDP) from WAN to LAN. If I NAT through on the typical ports (5900 and 3389, respectively) it works. If I try redirecting from something else (namely, 80) it doesn't work - they give me protocol errors.  This worked when I had monowall on the same box.

      I thought it might be "Disable webConfigurator redirect rule", so I unchecked that to ensure it wasn't stealing port 80.

      Any ideas? Thanks!

      1 Reply Last reply Reply Quote 0
      • W
        wallabybob
        last edited by

        Please provide a screenshot (or text description) of the relevant port forward rule(s).

        1 Reply Last reply Reply Quote 0
        • C
          cmb
          last edited by

          It works fine, post a screenshot of what you're attempting.

          1 Reply Last reply Reply Quote 0
          • M
            miltimj
            last edited by

            Here are some excerpts from the config file:

            <nat><rule><source>
            <any><destination><network>wanip</network>
            <port>80</port></destination>
            <protocol>tcp</protocol>
            <target>10.6.49.10</target>
            <local-port>3389</local-port>
            <interface>wan</interface>

            <associated-rule-id>nat_4e0a8a425a47e2.02056250</associated-rule-id></any></rule>
            …. removed ...</nat>

            <filter><rule><source>
            <any><interface>wan</interface>
            <protocol>tcp</protocol>
            <destination><address>10.6.49.10</address>

            <port>3389</port></destination>

            <associated-rule-id>nat_4e0a8a425a47e2.02056250</associated-rule-id></any></rule>
            … removed ...</filter>

            1 Reply Last reply Reply Quote 0
            • M
              miltimj
              last edited by

              Here's the screenshot (attached)…

              ![NAT rule 80 to 3389.JPG](/public/imported_attachments/1/NAT rule 80 to 3389.JPG)
              ![NAT rule 80 to 3389.JPG_thumb](/public/imported_attachments/1/NAT rule 80 to 3389.JPG_thumb)

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                That's correct, that will send 80 to 3389 on that internal IP. If you're not getting through with that, your ISP is most likely not allowing port 80 in. You can confirm by doing a packet capture on WAN with the host the remote host's public IP you're trying from and port 80, if you don't see that traffic in packet capture it's not getting to you, most likely because your ISP is blocking it.

                1 Reply Last reply Reply Quote 0
                • M
                  miltimj
                  last edited by

                  I can telnet to port 80 and it connects fine - it's the RDP protocol that seems to be getting mangled and not able to establish a connection.  This goes for the VNC protocol as well - I can telnet to port 80 when I forward to 5900 and it establishes a connection, but the VNC client can't establish a connection. So I know it's getting through to the LAN system.

                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    The only change it makes to the packets is rewriting the destination port, it's not possible for it to be mangled in a means that does anything to the protocol within (if anything it changes were broken, you would never get a connection via telnet as it would break the most basic of TCP communications). Those aren't exactly easy protocols to troubleshoot via packet capture since they aren't nicely decipherable like HTTP, SMTP, others, but that's worth a shot.

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