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

    Squid not listening on port 80

    Scheduled Pinned Locked Moved Cache/Proxy
    33 Posts 15 Posters 30.8k Views 1 Watching
    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 Offline
      Cino
      last edited by

      'Reverse Proxy interface' - select loopback as the interface…  use a higher port like 8443 or 9443 for 'reverse HTTPS port'

      1 Reply Last reply Reply Quote 0
      • J Offline
        joppybt
        last edited by

        @Cino:

        'Reverse Proxy interface' - select loopback as the interface…  use a higher port like 8443 or 9443 for 'reverse HTTPS port'

        In stead of using loopback I first set up the NAT to redirect WAN 443 to port 8443 on the LAN-IP of pfSense and had Squid listen to the LAN interface. This works fine.

        Now I changed the NAT to redirect to 127.0.0.1 and have Squid listen to loopback. This also work fine.

        Is there a reason to prefer one method over the other?

        1 Reply Last reply Reply Quote 0
        • marcellocM Offline
          marcelloc
          last edited by

          @joppybt:

          Is there a reason to prefer one method over the other?

          If you do not need to listen on lan, listen on a interface that nobody has direct access to.

          Treinamentos de Elite: http://sys-squad.com

          Help a community developer! ;D

          1 Reply Last reply Reply Quote 0
          • C Offline
            CubedRoot
            last edited by

            Gah! I just got hit with this one.  I just got my authetication issues figured out and decided to tighten up my proxy setup.  So, the first and only thing I did was try to set my proxy to a port lower than 1024.

            Checking the logs, it appears the squid process isn't able to open ports below 1024 since they are reserved ports…only root can.

            But, Squid 2 is able to open ports below 1024 without any issues.  Squid3 isnt.

            Has there been much movement on allowing squid to open ports below 1024?  I have tried adjusting the sysctl parameters with no luck.

            1 Reply Last reply Reply Quote 0
            • C Offline
              CubedRoot
              last edited by

              Actually,
              I was able to get the kernel to allow non-root users to open ports below 1024 by tweaking this kernel parameter:

              net.inet.ip.portrange.reservedhigh=20
              

              I just added that line to my /etc/sysctl.conf file.  Be sure to adjust the port to whatever you like.  I did 15 just for testing, and put squid on port 30.
              Once you edit that file, you will need to reload the parameters by doing a

              sysctl -a
              

              from the command line.

              Or, you can actually do this from the systems tuneables menu on the web page.
              Goto System > Advanced then click on the "System Tuneables" tab.
              Scroll to the bottom, and click the little "+" icon to add a new tuneable rule.
              For the Tuneable field use:

              net.inet.ip.portrange.reservedhigh
              

              And for the value field, put what ever the lowest port you want to allow normal users to open.  I did 15 in my example. Then hit save.

              Here is what it looks like:
              http://i.imgur.com/5XXNsI1.png

              While this isn't a good thing to do for security, I have honestly felt that the reserved ports in Linux is a dinosaur.  This is a good workaround.

              1 Reply Last reply Reply Quote 0
              • marcellocM Offline
                marcelloc
                last edited by

                I'll include this information on squid gui alert.
                Thanks for your feedback.

                Treinamentos de Elite: http://sys-squad.com

                Help a community developer! ;D

                1 Reply Last reply Reply Quote 0
                • K Offline
                  kaioh
                  last edited by

                  Hi, I had this problem too and while waiting for a FIX I had to configure a NAT on the loopback interface for each WAN connection.

                  It works but it's not very nice.

                  Waiting for a patch  ;D

                  .: Kaioh :.

                  1 Reply Last reply Reply Quote 0
                  • D Offline
                    droehn
                    last edited by

                    HI @ll,

                    I had the same issue after upgrading to 2.2 and managed to fix my reverse proxy by listening on loopback and natting port 80 to 10080. So far so good.

                    Any cname record is redirected as desired (mail.mydomain.com, ftp.mydomain.com etc.) but NOT the common www.mydomain.com - even though I generated several redirection regex entries like ^http://www.mydomain.com/.*$.

                    It looks like it could not resolve this redirection and therefore want to stay on the pfsense, turning http to https in the browser's web address field and ending up with timeout error (site not available). This behaviour occurs only when trying to reach www.mydomain.com from the WAN.

                    Any hints from you guys?
                    Thanks and regards
                    Dave

                    1 Reply Last reply Reply Quote 0
                    • S Offline
                      Spix
                      last edited by

                      I have similar problem, https://forum.pfsense.org/index.php?topic=90885.0

                      1 Reply Last reply Reply Quote 0
                      • D Offline
                        droehn
                        last edited by

                        Issue solved - somehow!

                        I use a captive portal which maintains a local web server on the pfsense. When I disable the captive portal, a call for www.mydomain.com is redirect over the reverse proxy to the right destination as required

                        After upgrade from 2.1 to 2.2 it seems to have mixed something up in the captive portal settings. Have not yet figured out details, but it looks like such local webserver was in priority before going into NAT for 80 to 10080. Does not explain why it turned a port 80 call into 443 (and why problem did not exist on requests from LAN), but that is something I have to examine next.

                        Best regards
                        Dave

                        1 Reply Last reply Reply Quote 0
                        • M Offline
                          MacUsers
                          last edited by

                          Happy Easter Sunday Guys!

                          It would even happier if I could make the Squid work. Upgraded to v2.2.1 yesterday and went through this post top to bottom but still can make it work. What I want to do is access the ip-camera, which is running on 10.0.11.21:8081 using the URL: lhdome.mydomain.co.uk/01
                          As suggested, configured a NAT to redirect traffic for port 80 to 8080 on loopback address and set Squid to listen on loopback address. This is what my settings are now:

                          Reverse Proxy server: General

                          Reverse Proxy server: Peers

                          Reverse Proxy server: Mappings: Edit

                          Firewall: NAT: Port Forward

                          I get 404 - Not Found in return. Any one out here can tell me what I'm doing wrong or missing please? Best!

                          1 Reply Last reply Reply Quote 0
                          • J Offline
                            joppybt
                            last edited by

                            My guess:

                            Squid in reverse proxy mode will do all kind of port-redirecting but it will do no URL-rewriting.

                            In the end a request for 10.0.11.21:8081**/01** is sent to the camera, which will not understand the /01 part resulting in the 404

                            1 Reply Last reply Reply Quote 0
                            • M Offline
                              MacUsers
                              last edited by

                              @joppybt:

                              In the end a request for 10.0.11.21:8081**/01** is sent to the camera, which will not understand the /01 part resulting in the 404

                              Point taken!
                              So, took different approach: changed lhdome to lhdome1 and URI to lhdome1.mydomain.co.uk - and now I get the pfSence web-gui login screen with that URI. Something still wrong, I believe? Best!

                              1 Reply Last reply Reply Quote 0
                              • A Offline
                                amason
                                last edited by

                                @marcelloc:

                                I'll include this information on squid gui alert.
                                Thanks for your feedback.

                                Hi Marcello,

                                Thanks for your work on this, it's working great now.  Note that with pfSense 2.2.2 and squid3 0.2.8 package installed from GUI, there's no warning about the port issue during install or at service start.

                                I had to go through a few steps to go from a NATted port 80 to a reverse proxy, thought I'd put them here for reference:

                                • I had my pfSense webGUI on LAN port 80 before starting, and a NAT on WAN port 80 to a web server on the LAN

                                • removed the NAT for port 80

                                • moved the webGUI to an alternate port, and unchecked System -> Advanced -> Admin Access -> WebGUI redirect

                                • added sysctl net.inet.ip.portrange.reservedhigh=79 to System -> Advanced -> System Tunables (and reboot or set it live on the CLI)

                                • enabled the reverse proxy, created Web Servers and Mappings

                                • added the rule to allow port 80 on the WAN Address

                                At one point in the process, I had added the rule to allow WAN access to port 80, and I hadn't yet moved the webGUI (because I thought I could leave it on LAN port 80 as before, but alas…).  That exposed the webGUI to the world.  Oops.

                                At the next point, I hadn't yet added the sysctl required to get the reverse proxy process to start on port 80 as a non-privileged user (because there was no warning, and the log is in a funny place, and I didn't know about 'sockstat' at the time).  That also exposed the webGUI to the world.  More Oops.

                                --
                                Andy

                                1 Reply Last reply Reply Quote 0
                                • J Offline
                                  jbeezer
                                  last edited by

                                  Hello,

                                  Long time user of pfsense, first time poster.

                                  I just installed 2.2.4 on my netgate and can confirm that I saw a warning message when enabling a reverse proxy (squid 0.2.8) telling me to set net.inet.ip.portrange.reservedhigh to 0 in system tunables.  After doing just that and restarting that squid service everything just works!

                                  Nice work guys!  I continue to be more and more impressed with what pfsense can do.

                                  1 Reply Last reply Reply Quote 0
                                  • G Offline
                                    gglockner
                                    last edited by

                                    I'm having similar issues.  I am using pfSense 2.2.6 and squid3.

                                    I can get squid3 to do reverse http proxy on port 8000, listening on the LAN interface. I can confirm that it's working using a computer on the LAN.  It also works correctly if it is listening on the WAN interface and I enable port 8000 in the firewall.

                                    Now I want to do reverse http proxying on the WAN, using port 81.  I setup the following NAT Port Forwarding:

                                    WAN  TCP  *  *  WAN address  81  192.168.1.1  8000

                                    It also has an associated firewall rule.  Now if I go to an external computer and visit:

                                    http://www.mydomain.com:81

                                    I now get a Squid error: "Access Denied. Access control configuration prevents your request from being allowed at this time."  So it looks like Squid is rejecting the request.  If I look at the Squid - Access Logs, I see TCP_DENIED/403 for this request.  Any help would be appreciated.


                                    I found the fix here: https://forum.pfsense.org/index.php?topic=96782.msg538767#msg538767 - I simply needed to add port 81 to the list of ACL SafePorts.

                                    1 Reply Last reply Reply Quote 0
                                    • O Offline
                                      Ocean7
                                      last edited by

                                      Still having the same issue on 2.4.5-RELEASE (amd64) :(
                                      I checked config for illegal characters and it all looks good!
                                      However, as soon as I add another "Web Server" half of all requests from all domains are being forwarded to that new web server.

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