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

    Port forwarding port 80 sends requests back to the pfSense web interface

    Scheduled Pinned Locked Moved NAT
    18 Posts 6 Posters 12.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.
    • JSmoradaJ
      JSmorada
      last edited by

      I'm trying to move one of my .com domains from a hosting platform back to my own web server. In pfSense 1.2.3 I had absolutely no problems forwarding traffic to my internal web server but now I can't seem to get it working. I know I'm probably missing something simple but here's what happens.

      This should serve webpage.com to the outside world:
      WAN > pfSense set to forward port 80 to LAN ip address www.xxx.yyy.zz port 80.

      Instead, I'm seeing the pfSense web configurator whether I use a browser on my internal LAN or from a public address. Obviously this is a major security risk so I rolled back the dns entry with my domain registrar to the default.

      Help this idiot figure this out :-[

      Thanks,
      Jonny

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

        WAN > pfSense set to forward port 80 to LAN ip address www.xxx.yyy.zz port 80.

        WAN > pfSense set to forward port 80 to WAN address www.xxx.yyy.zz port 80.

        www.xxx.yyy.zz should be the private, inside, real IP address of the listening server.

        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
        • chpalmerC
          chpalmer
          last edited by

          @nipstech:

          WAN > pfSense set to forward port 80 to LAN ip address www.xxx.yyy.zz port 80.

          Instead, I'm seeing the pfSense web configurator
          Help this idiot figure this out :-[

          Thanks,
          Jonny
          [/quote]

          Nah- your not an idiot.  ;D

          Go to "System/Advanced

          Select HTTPS at protocol if it is not already. (just for good sense)

          Go down to  "WebGUI redirect" and check the box.

          If you want to use port 443 for something else other than the firewall then set your port to something else.  You will have to remember to add :port to the log in address but soon it will become second nature.  :)

          I.E.  https://your box.com:448

          You may have to re-log in with the new port at this point.

          Triggering snowflakes one by one..
          Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

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

            Unnecessary. Port forwards take precedence over both HTTP redirects and webgui. His port forward was hosed.

            ![Screen Shot 2016-04-28 at 11.12.13 PM.png](/public/imported_attachments/1/Screen Shot 2016-04-28 at 11.12.13 PM.png)
            ![Screen Shot 2016-04-28 at 11.12.13 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2016-04-28 at 11.12.13 PM.png_thumb)
            ![Screen Shot 2016-04-28 at 11.12.38 PM.png](/public/imported_attachments/1/Screen Shot 2016-04-28 at 11.12.38 PM.png)
            ![Screen Shot 2016-04-28 at 11.12.38 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2016-04-28 at 11.12.38 PM.png_thumb)
            ![Screen Shot 2016-04-28 at 11.16.51 PM.png](/public/imported_attachments/1/Screen Shot 2016-04-28 at 11.16.51 PM.png)
            ![Screen Shot 2016-04-28 at 11.16.51 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2016-04-28 at 11.16.51 PM.png_thumb)

            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
            • chpalmerC
              chpalmer
              last edited by

              @Derelict:

              Unnecessary. Port forwards take precedence over both HTTP redirects and webgui. His port forward was hosed.

              Ive done more than a few of these and its always been the fix…  Wont say Im not wrong but there is that lack of all needed information to actually know whats going on...

              mindread.jpg
              mindread.jpg_thumb

              Triggering snowflakes one by one..
              Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

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

                Just posted the config. Same result with HTTP checked instead of HTTPS in System > Advanced (with the exception that, as expected, I can no longer get to the WebGUI since TCP/80's forwarded to the internal host and WebGUI is no longer listening on HTTPS).

                This is one of those "Legends of pfSense" that likely has more basis in outdated, amateur youtube walkthroughs than in reality. Maybe it used to be the case.

                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
                • chpalmerC
                  chpalmer
                  last edited by

                  @Derelict:

                  Just posted the config. Same result with HTTP checked instead of HTTPS in System > Advanced (with the exception that, as expected, I can no longer get to the WebGUI since TCP/80's forwarded to the internal host and WebGUI is no longer listening on HTTPS).

                  I will have to play later…

                  Ive been using since pre 1. days so may have skewed understanding here and there.

                  nipstech-  anything to add?    ;D

                  Triggering snowflakes one by one..
                  Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

                  1 Reply Last reply Reply Quote 0
                  • JSmoradaJ
                    JSmorada
                    last edited by

                    I re-created the NAT and now it's working…I'm puzzled???

                    2016-04-29_7-42-08.png
                    2016-04-29_7-42-08.png_thumb

                    1 Reply Last reply Reply Quote 0
                    • JSmoradaJ
                      JSmorada
                      last edited by

                      Now I'm having a different problem. When I try to access a web page on one of the domains I'm hosting locally using my local network (LAN) it times out. When I try to access it from a public network (OPT1) I get a "connection reset" error.  The IIS log shows the packets never reach the server.

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

                        @nipstech:

                        Now I'm having a different problem. When I try to access a web page on one of the domains I'm hosting locally using my local network (LAN) it times out.

                        You're probably using an external DNS server for your LAN hosts. Have you tried entering a host override in your DNS settings to resolve the domain name against an internal address? As for the second issue, have you checked the routing on your web server is correct?

                        1 Reply Last reply Reply Quote 0
                        • JSmoradaJ
                          JSmorada
                          last edited by

                          For my internal (LAN) hosts I'm using MS DNS since I have an Active Directory domain. The domain's DNS is set to forward external requests to pfSense. pfSense is set to use 127.0.0.1 and OpenDNS. I'm not sure what you mean by routing but IIS is bound to the server's IP address and host headers both with and without the www.

                          ![Domain DNS .png](/public/imported_attachments/1/Domain DNS .png)
                          ![Domain DNS .png_thumb](/public/imported_attachments/1/Domain DNS .png_thumb)
                          ![IIS Bindings.png](/public/imported_attachments/1/IIS Bindings.png)
                          ![IIS Bindings.png_thumb](/public/imported_attachments/1/IIS Bindings.png_thumb)

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

                            Ok, so let me rephrase it: When you do a lookup against your web site name (I assume www.birch.net) from within your LAN do you get your web server's internal address or the external (internet-facing) address? The routing I refer to concerns the web server. Is it's default gateway set to the firewall where the returning traffic has to lead back through?

                            1 Reply Last reply Reply Quote 0
                            • JSmoradaJ
                              JSmorada
                              last edited by

                              When I do a lookup I see the external address. The default gateway on the server points to the firewall.

                              UPDATE: I changed the DNS settings on the firewall and deleted the 127.0.0.1 entry. Now I can access the web server from my LAN but when trying to access it from OPT1 I get the message that the connection was reset.

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

                                @Derelict:

                                Just posted the config. Same result with HTTP checked instead of HTTPS in System > Advanced (with the exception that, as expected, I can no longer get to the WebGUI since TCP/80's forwarded to the internal host and WebGUI is no longer listening on HTTPS).

                                This is one of those "Legends of pfSense" that likely has more basis in outdated, amateur youtube walkthroughs than in reality. Maybe it used to be the case.

                                Correct. It never has been the case. pf rdr (port forwards) always override anything listening locally on the system.

                                What some people probably end up with in that case is the HTTP->HTTPS redirect cached in their browser from before reflection was enabled, and browsers really want to hold onto those redirects. So then they always get sent by their browser to HTTPS when trying to get to the HTTP, don't have the HTTPS port forwarded, so hit the GUI (because they're actually browsing straight there, their browser just doesn't make that clear that it's not even trying the HTTP connection anymore). They screw around with it long enough, and refresh enough times, that the browser gives up on the redirect. Then "disabling the redirect fixed it!" because they didn't change anything else, so surely that had to be it, right? No.

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

                                  @nipstech:

                                  When I do a lookup I see the external address.

                                  This problem comes up a lot on this forum. Your LAN clients are trying to access a local web server by bouncing the traffic off your firewall's external address back into your LAN/DMZ. The better way to do this is to create an A record in your AD DNS server for your internal web server resolving to it's internal address. That way traffic on your local network will stay in your local network and hit the web server directly. Your external DNS should resolve to the external address so that the traffic is correctly directed to outside firewall interface.
                                  @nipstech:

                                  I changed the DNS settings on the firewall and deleted the 127.0.0.1 entry. Now I can access the web server from my LAN but when trying to access it from OPT1 I get the message that the connection was reset.

                                  Sounds like your port forward rule isn't correct. Post your NAT and firewall rules for the WAN-2-LAN traffic to your web server.

                                  1 Reply Last reply Reply Quote 0
                                  • JSmoradaJ
                                    JSmorada
                                    last edited by

                                    Ok here they are…
                                    I really appreciate all the help :)

                                    NAT.png
                                    NAT.png_thumb
                                    Rule.png
                                    Rule.png_thumb

                                    1 Reply Last reply Reply Quote 0
                                    • chpalmerC
                                      chpalmer
                                      last edited by

                                      @cmb:

                                      Correct. It never has been the case. pf rdr (port forwards) always override anything listening locally on the system.

                                      What some people probably end up with in that case is the HTTP->HTTPS redirect cached in their browser from before reflection was enabled, and browsers really want to hold onto those redirects. So then they always get sent by their browser to HTTPS when trying to get to the HTTP, don't have the HTTPS port forwarded, so hit the GUI (because they're actually browsing straight there, their browser just doesn't make that clear that it's not even trying the HTTP connection anymore). They screw around with it long enough, and refresh enough times, that the browser gives up on the redirect. Then "disabling the redirect fixed it!" because they didn't change anything else, so surely that had to be it, right? No.

                                      Im trying to remember where I got this "bad behavior" but would have only taken once for me to hold onto it.  :o ;D    Since I use a different port on the GUI anyways Ive never really tested it after the first time.

                                      Triggering snowflakes one by one..
                                      Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

                                      1 Reply Last reply Reply Quote 0
                                      • K
                                        KrazeyKami
                                        last edited by

                                        @chpalmer:

                                        @cmb:

                                        Correct. It never has been the case. pf rdr (port forwards) always override anything listening locally on the system.

                                        What some people probably end up with in that case is the HTTP->HTTPS redirect cached in their browser from before reflection was enabled, and browsers really want to hold onto those redirects. So then they always get sent by their browser to HTTPS when trying to get to the HTTP, don't have the HTTPS port forwarded, so hit the GUI (because they're actually browsing straight there, their browser just doesn't make that clear that it's not even trying the HTTP connection anymore). They screw around with it long enough, and refresh enough times, that the browser gives up on the redirect. Then "disabling the redirect fixed it!" because they didn't change anything else, so surely that had to be it, right? No.

                                        Im trying to remember where I got this "bad behavior" but would have only taken once for me to hold onto it.  :o ;D    Since I use a different port on the GUI anyways Ive never really tested it after the first time.

                                        Not to resurrect any posts here… But I ran into the same issue as OP. Only my NAT rules were correct (as proposed by Derelict). In my experience, on PfSense 2.3.4, PF RDR does not take precedence, and will cause you to get locked out of the gui if you configure it to forward 80 to a different server. The only thing that works, is as ChPalmer describes; Change the port the WebGUI is listening on and disable the redirect, so it doesn't keep listening on 80. Then, and only then, the PF succeeds. To reflect on CMB; It was not a browser cache in my case. For the OP's 'other' issue; You probably forgot to open 80 somewhere on your destination server (or along the route).

                                        Why this comment?
                                        If PF RDR should take precedence always, which would be a great feature, it is not working. Maybe a bug fix is in order.

                                        Thanks all.

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