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

    NAT to port 80 broken but NAT to port 81 works / SYN but no ACK

    Scheduled Pinned Locked Moved NAT
    4 Posts 4 Posters 1.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.
    • C
      caldwell
      last edited by

      I have a NAT forward to a web server on the LAN.  I have a rule allowing traffic from any host to the WAN address.

      Rules look like this:
      IPv4 TCP * * webserver 80 (HTTP) * none
      IPv4 TCP * * webserver 81         * none

      NAT looks like this:
      WAN TCP * * WAN address 80 (HTTP) webserver 80 (HTTP)
      WAN TCP * * WAN address 81         webserver 80 (HTTP)

      When I try to telnet to port 80 from a box outside the network, I get this in tcpdump:

      IP 1.2.3.4.55826 > 172.16.17.3.http: S 3025942183:3025942183(0) win 14600 <mss 8="" 4095152271="" 1460,sackok,timestamp="" 0,nop,wscale="">IP 172.16.17.3.http > 1.2.3.4.55826: S 474696829:474696829(0) ack 3025942184 win 5792 <mss 7="" 79668196="" 1460,sackok,timestamp="" 4095152271,nop,wscale="">IP 1.2.3.4.55826 > 172.16.17.3.http: S 3025942183:3025942183(0) win 14600 <mss 8="" 4095153271="" 1460,sackok,timestamp="" 0,nop,wscale="">P 172.16.17.3.http > 1.2.3.4.55826: S 474696829:474696829(0) ack 3025942184 win 5792 <mss 7="" 79669196="" 1460,sackok,timestamp="" 4095152271,nop,wscale="">Basically, SYN with no ACK making it back to the client.

      If I telnet to port 81 on the WAN interface (which is redirected to port 80 on the webserver), I get this:
      IP 1.2.3.4.49708 > 172.16.17.3.http: S 664973534:664973534(0) win 14600 <mss 8="" 4095141468="" 1460,sackok,timestamp="" 0,nop,wscale="">IP 172.16.17.3.http > 1.2.3.4.49708: S 415957:415957(0) ack 664973535 win 5792 <mss 7="" 79657405="" 1460,sackok,timestamp="" 4095141468,nop,wscale="">IP 1.2.3.4.49708 > 172.16.17.3.http: . ack 1 win 58 <nop,nop,timestamp 79657405="" 4095141737="">IP 1.2.3.4.49708 > 172.16.17.3.http: P 1:6(5) ack 1 win 58 <nop,nop,timestamp 79657405="" 4095143558="">IP 172.16.17.3.http > 1.2.3.4.49708: . ack 6 win 46 <nop,nop,timestamp 79659493="" 4095143558="">So, full success.  No problems.

      I'm trying to figure out why port 81 NAT forward to port 80 webserver WORKS but port 80 NAT forward to port 80 web server does NOT work.

      I've turned off squid and tested it.  No change.  I've tried tweaking different settings, variables.  No change.

      Anyone have any bright ideas?</nop,nop,timestamp></nop,nop,timestamp></nop,nop,timestamp></mss></mss></mss></mss></mss></mss>

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

        Maybe PFSense is using port 80 for its web interface?

        1 Reply Last reply Reply Quote 0
        • DerelictD
          Derelict LAYER 8 Netgate
          last edited by

          I thought NAT took precedence over services listening on the firewall.

          But a quick test would be to be sure the web configurator is set to:

          Protocol: HTTPS
          WebGUI redirect: Unchecked

          These are on System > Advanced, Admin Access tab

          Chattanooga, Tennessee, USA
          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
          Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

            The server's sending the SYN ACK in response, the question is why doesn't it get to the client. Does it leave WAN?

            @Derelict:

            I thought NAT took precedence over services listening on the firewall.

            It does, that's not relevant here.

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