Redirect Target Port not working 2.0-RC3

[miltimj]

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!

[wallabybob]

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

[cmb]

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

[miltimj]

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>

[miltimj]

Here's the screenshot (attached)…


[cmb]

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.

[miltimj]

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.

[cmb]

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.