The pfSense Store

Author Topic: Redirect Target Port not working 2.0-RC3  (Read 1399 times)

0 Members and 1 Guest are viewing this topic.

Offline miltimj

  • Newbie
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Redirect Target Port not working 2.0-RC3
« on: July 12, 2011, 12:55:59 pm »
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!

Offline wallabybob

  • Hero Member
  • *****
  • Posts: 5262
  • Karma: +0/-0
    • View Profile
Re: Redirect Target Port not working 2.0-RC3
« Reply #1 on: July 12, 2011, 05:14:26 pm »
Please provide a screenshot (or text description) of the relevant port forward rule(s).

Offline cmb

  • Administrator
  • Hero Member
  • *****
  • Posts: 6333
  • Karma: +0/-0
    • LinkedIn
    • Twitter
    • View Profile
    • Chris Buechler
Re: Redirect Target Port not working 2.0-RC3
« Reply #2 on: July 12, 2011, 08:42:39 pm »
It works fine, post a screenshot of what you're attempting.

Offline miltimj

  • Newbie
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: Redirect Target Port not working 2.0-RC3
« Reply #3 on: July 13, 2011, 03:21:11 am »
Here are some excerpts from the config file:

<nat>
   <rule>
      <source>
         <any/>
      </source>
      <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>
      <descr><![CDATA[RDP to Desktop (port 80)]]></descr>
      <associated-rule-id>nat_4e0a8a425a47e2.02056250</associated-rule-id>
   </rule>
.... removed ...
</nat>

<filter>
   <rule>
      <source>
         <any/>
      </source>
      <interface>wan</interface>
      <protocol>tcp</protocol>
      <destination>
         <address>10.6.49.10</address>
         <port>3389</port>
      </destination>
      <descr><![CDATA[NAT RDP to Desktop (port 80)]]></descr>
      <associated-rule-id>nat_4e0a8a425a47e2.02056250</associated-rule-id>
   </rule>
... removed ...
</filter>



Offline miltimj

  • Newbie
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: Redirect Target Port not working 2.0-RC3
« Reply #4 on: July 13, 2011, 03:24:08 am »
Here's the screenshot (attached)...

Offline cmb

  • Administrator
  • Hero Member
  • *****
  • Posts: 6333
  • Karma: +0/-0
    • LinkedIn
    • Twitter
    • View Profile
    • Chris Buechler
Re: Redirect Target Port not working 2.0-RC3
« Reply #5 on: July 13, 2011, 03:59:54 am »
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.

Offline miltimj

  • Newbie
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: Redirect Target Port not working 2.0-RC3
« Reply #6 on: July 13, 2011, 05:47:33 am »
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.

Offline cmb

  • Administrator
  • Hero Member
  • *****
  • Posts: 6333
  • Karma: +0/-0
    • LinkedIn
    • Twitter
    • View Profile
    • Chris Buechler
Re: Redirect Target Port not working 2.0-RC3
« Reply #7 on: July 13, 2011, 06:24:20 am »
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.