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

    Port forwarding HTTP and HTTPS dont work on pfsense 2.4.0 (sg2220).

    Scheduled Pinned Locked Moved NAT
    12 Posts 2 Posters 7.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.
    • S
      starr
      last edited by

      Hi forwarding http(80) and https(443) to my webserver is not working at all. This is super weird as all of my other NAT forwarding rrules work(ex plex and other high port applications).
      After many houers of pulling my hair out I was not able to find a solution.. So i decided to reinstall pfsense completly.

      Reinstalling pfsense did not work either..

      So im sitting here with a fresh pfsense box with default config, and it is still not working..

      This is my NAT port forward rule(see Attachment)

      The rule is showing up in Rules-wan(see Attachment)

      I can see the SYN in the state table(see Attachment)


      The source is my cellphone using mobile data..

      The webserver is accessible to all clients on lan. There is no firewall running on the webserver.
      My ISP is not blocking any ports

      If i change the port forward rule to NAT traffic from port 8085 to 80 it is working as expected(see Attachment).

      Why is cant I forward HTTP to HTTP ?

      A friend of mine with a sg 2220 is running a default setup with pfsense version 2.3.2-RELEASE. He is using the exact same settings and NAT rules which is working..

      EDIT:
      I am tring to access my webserver from remote clients via my external IP over TCP port 80.
      NAT.PNG
      NAT.PNG_thumb
      fw_rule.PNG
      fw_rule.PNG_thumb
      NAT_8085.PNG
      NAT_8085.PNG_thumb
      state_details.PNG
      state_details.PNG_thumb
      state_table.jpg
      state_table.jpg_thumb

      1 Reply Last reply Reply Quote 0
      • johnpozJ
        johnpoz LAYER 8 Global Moderator
        last edited by

        So sniff on your lan side interface.. Are you seeing the syn go and the syn,ack back from the server?

        Your state table when you changed it to 8085 is the same as your 80 forward.

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.8, 24.11

        1 Reply Last reply Reply Quote 0
        • S
          starr
          last edited by

          I did sniff the traffic on pfsense LAN interface as well as on the web server.

          Both packet dumps shows that the webserver is reciving the SYN and replying with SYN ACK. But it seems like the SYN ACK is never recived by the client.. As TCP retransmission is occurring..

          Screen dump of pfsense LAN interface:

          Screen dump of webserver interface:

          This is not a issue with the webserver, I can run

          sudo python -m 'SimpleHTTPServer' 80
          

          to start a simpleHTTP instance on port 80 on my workstation or any other VM,(and changing the NAT rule accordingly) and the behavior is still the same..

          Edit:
          Change the port to 8085 shows "ESTABLISHED:ESTABLISHED" in the state table

          PF_lan.PNG
          PF_lan.PNG_thumb
          web_int.PNG
          web_int.PNG_thumb

          1 Reply Last reply Reply Quote 0
          • johnpozJ
            johnpoz LAYER 8 Global Moderator
            last edited by

            Makes no sense.. your saying if your forward 8085 to 80 works..  But if 80 to 80 fails.

            Do you have any floating rules?  Are you running transparent proxy?  You only have the 1 wan, no vpn setup for routing.  Possible pfsense doesn't know where to send the syn,ack back?  There is nothing in the firewall log.  If the traffic was out of state pfsense should log that it blocked it.

            Are you using any vlan tags?  Did you validate that the syn,ack back is going to the correct mac address

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 24.11 | Lab VMs 2.8, 24.11

            1 Reply Last reply Reply Quote 0
            • S
              starr
              last edited by

              Yes I know this makes absolutly no sense..

              No  floating rules, no proxy, no VPN. This is a clean install of pfsnese. Only one WAN, and one LAN port.

              However i have two vlans: HOME - vlan 20 - tagged(192.168.2.1/24) , GUEST - vlan 30 - tagged(192.168.3.1/24). Currently no FW or NAT rules other than the "default" allow internett..

              I also have the interface "LAN" which is not a VLAN, just a normal interface(192.168.1.1/24) - this is were the traffic in question is flowing.

              The packet dump shows that the syn ack have the "LAN"(pfsense) interface as the destinaiton, which is correct.

              FW logs do show that the traffic gets blocked(see attachment)

              fw_log.PNG
              fw_log.PNG_thumb

              1 Reply Last reply Reply Quote 0
              • S
                starr
                last edited by

                A packet dump form the pfsense WAN inteface shows SYN traffic from the client, but SYN ACK is never transmitted by pfsense. So when the webserver recives the SYN, it responds with the SYN ACK and then pfsense discards thoes packets some how.. Why this is happending is super wierd..

                1 Reply Last reply Reply Quote 0
                • johnpozJ
                  johnpoz LAYER 8 Global Moderator
                  last edited by

                  So hold on.. Your firewall rule is showing blocked… This is the SYN coming in from the net.. But you show pfsense forwarding the traffic out the lan to your forward?

                  Would you mind me Teamviewer to your machine and we could take a look?  PM the info and can take a look see to what is going on... This is ODD as shit!

                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                  If you get confused: Listen to the Music Play
                  Please don't Chat/PM me for help, unless mod related
                  SG-4860 24.11 | Lab VMs 2.8, 24.11

                  1 Reply Last reply Reply Quote 0
                  • S
                    starr
                    last edited by

                    PM sent

                    1 Reply Last reply Reply Quote 0
                    • johnpozJ
                      johnpoz LAYER 8 Global Moderator
                      last edited by

                      So update to this.. I TV in… And yeah its strange... But pfsense looks to be working just fine.

                      We did a sniff on wan and lan.. And you can see the forward work, server behind answers with syn,ack and pfsense gets this and sends it out the wan interface..

                      The only thing that makes sense is that port 80 as source port outbound is blocked somewhere upstream from pfsense.  The gateway which is bridge mode was not reachable via http but answered ping on 192.168.100.1 -- he was going to try and reset the modem.. Reboot of it did not help.

                      This would explain why using 8085 to 80 works.  Since the return traffic leaving pfsense back to the internet would have source port of 8085 vs 80..

                      https on 443 was working when we tested it.

                      Very Strange!!

                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                      If you get confused: Listen to the Music Play
                      Please don't Chat/PM me for help, unless mod related
                      SG-4860 24.11 | Lab VMs 2.8, 24.11

                      1 Reply Last reply Reply Quote 0
                      • S
                        starr
                        last edited by

                        I sent a fairly detailed mail to my ISP regarding my and johnpoz findings and suspected that my ISP router was the problem.
                        The ISP replied that the port 80 was closed due to "security reasons"… Even thou I called my ISP earlier that week and asked specifically if they did block that port and the answer was no...  This must be a new "security policy" they have applied as the port 80 was "open for forwarding" 1-2 years back on the same router.

                        But still I can't quite wrap my head around how they block port 80 when the router is in bridge mode? Unless they block it some where in the "ISP net"..

                        So no problem or bug with Pfsense!:) And many thanks to johnpoz for giving me some really good help:D

                        1 Reply Last reply Reply Quote 0
                        • johnpozJ
                          johnpoz LAYER 8 Global Moderator
                          last edited by

                          Well clearly they are not blocking it INBOUND.. Since you see the syn come into pfsense wan..

                          What they are doing is blocking any traffic outbound from your network from a source port of 80, ie your answer to anything inbound.

                          Don't see why they just don't block it inbound.. Would make it so much easier for you to see that is where the problem is ;)  But this way guess they can say when users call.. We do not block inbound traffic to you.. And just to forget to mention that we will not allow your return traffic from that port though ;) hehehe

                          But if they were worried about so called "security" issues for their users and inbound traffic on 80.. Say for example IP camera's etc that the users have opened and get exploited via some web ui, etc.  Then they should block it inbound into your IP.

                          As to how they do it - real simple, you transverse their network to get to and from the internet.  They can block any port or protocol they want..

                          Thanks for updating the thread - puts that issue to bed I guess.  Will they open it for you on special request.  Does their website state anything about blocking traffic for their services?  How come it works for your buddy?  Guess they have not gotten around to blocking it on his connection yet?  They really should clearly state what they do for "security" when you sign up for their service.  Many isp block outbound on 25 for example (smtp) since home connections really have no need for such connectivity.. And for sure can reduce the number of spam bots their users would become ;)

                          443 was working.. Clear http is dying anyway.. Just host up what you need to host up via httpS..

                          An intelligent man is sometimes forced to be drunk to spend time with his fools
                          If you get confused: Listen to the Music Play
                          Please don't Chat/PM me for help, unless mod related
                          SG-4860 24.11 | Lab VMs 2.8, 24.11

                          1 Reply Last reply Reply Quote 0
                          • S
                            starr
                            last edited by

                            I asked about what the "security reason" was, but he could not tell me..:P And he instructed me to use port 8080 instead.. which is as much spammed as port 80 I guess.. They do not state in their website that any port is blocked by default or any thing about security for that matter.. I have put in a special request on opening port 80, we'll see how that goes..

                            As for my buddy, I don't really know, probably don't have the latest update is my guess.

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