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

    Squid/squidguard blocking port 80 to private(RFC 1918) ips

    pfSense Packages
    3
    6
    5.9k
    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.
    • P
      plunger
      last edited by

      We have 4 sites, connected by an mpls network.  At each site we have a pfsense (1.2.1) firewall controlling, among other things, cross site traffic.  These firewalls also control access to the web (separate interface from the MPLS link) at each site, so we are in the process of installing the squid(2.7.8_1) and squidguard(1.3-2) packages at each site to filter the nasty interwebs and access to them.

      Much of our internal infrastructure is housed at SiteA, including our intranet server.  This is just a simple Apache server running on port 80.  We have routing configured over our mpls so that all requests for the intranet web server (10.4.0.80) from sites other than SiteA get routed across the mpls to our pfsense firewall at SiteA and from there onto our intranet web server.

      So let's talk about SiteB.  At SiteB, users were able to hit the intranet web server at SiteA on port 80 without any trouble.  Then we install the squid and squidguard packages on the pfsense box at SiteB.  Suddenly, we have no access to the intranet web server from machines at SiteB.

      So, under Services->Proxy Server->General I check the "Bypass proxy for Private Address Space (RFC 1918) destination" option.  Save, apply, restart services, eventually restart firewall several times, google the issue, repeat all several times, etc.  No matter what, traffic from SiteB heading to the intranet web server at SiteA never gets to the firewall at SiteA.  Seeing as it had no trouble passing through prior to bringing squid/squidguard on line and seeing as there are no dropped packets showing up in the firewall log for such traffic, it looks as though it is squid and associates that are making my headache happen.

      Another note.  There are several subnets at SiteB that are not otherwise filtered by squid/squidguard.  As in, they are not selected in Services->Proxy Server->Proxy Interface.  Traffic from these interfaces is suffering the same fate as their proxied brethren.

      Can anyone point me in the right direction?

      Thanks
      -p

      1 Reply Last reply Reply Quote 0
      • P
        plunger
        last edited by

        <crickets>sigh</crickets>

        1 Reply Last reply Reply Quote 0
        • jimpJ
          jimp Rebel Alliance Developer Netgate
          last edited by

          Let me see if I'm understanding this right:

          At Site B, you have WAN, which goes to the internet, and an OPT link that goes via MPLS? Or is it just a box on LAN and some static routes?

          The problem is most likely that squid is trying to shove that traffic out WAN, which won't work if that isn't where your MPLS router is expecting the traffic to be.

          Once upon a time there was a thread here where someone altered the proxy redirect rule to exclude an IP or subnet, that might get you what you need if this is the case.

          It may also help to see a copy of your routing table on the site B box (netstat -rn or Diagnostics > Routes) along with the contents of /tmp/rules.debug with and without the 'bypass proxy for RFC 1918' option checked. It would also help to know if you're using squid transparently or via coding the proxy settings into the client systems.

          You can confirm if the traffic is being misrouted by watching with tcpdump on the WAN interface as you try to access your intranet site.

          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

          Need help fast? Netgate Global Support!

          Do not Chat/PM for help!

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

            This is the post that jimp was referring to - or one of them at least.
            http://forum.pfsense.org/index.php/topic,22142.msg113979.html#msg113979

            1 Reply Last reply Reply Quote 0
            • P
              plunger
              last edited by

              mhab12, thanks for the link, that is very close to what i need except that i'm looking to bypass the proxy for traffic to an private ip on the other side of my firewall.  hence, w/ 10.0.0.0/8 already listed in the rule, there aren't any changes to be made.

              jimp, lots of good details to look at, thanks.

              to answer your question:
              @jimp:

              Let me see if I'm understanding this right:

              At Site B, you have WAN, which goes to the internet, and an OPT link that goes via MPLS?

              ->exactly.  and we are running a transparent proxy.

              as for the routes and rules.debug, those are loaded with a bunch of our ips, internal and external.  i'm a bit green at this but if you wouldn't mind, i'd like to avoid posting them in their entirety to a public message board if possible.

              instead, maybe we can talk about how squid affects routing on a pfsense box.  i think this is what you were getting at when asking about the files above.  i did switch the 'bypass proxy for RFC 1918' on and off.  i couldn't find any changes in the routing tables, however i did notice that the line:
                no rdr on bge1 proto tcp from any to { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } port 80
              in /tmp/rules.debug came and went with that switch.  something else that i noticed is that attempts to hit the intranet site from SiteB also had different results when turning that option on/off.  w/ the switch on firefox just gave me a network timeout.  with the switch off i get a reply from squid noting essentially the same.  in both cases it seems that squid is doing what i tell it too, but the traffic is being routed out the wrong door.  so i had a look at tcp dump like you recommended.  sure enough requests for the intranet site are heading out the WAN link as opposed to the Opt link for the MPLS, where they'd find their way to the the server @ SiteA.

              it's important to note that this was not happening prior to the squid install as i have a rule that takes all traffic from the lan, heading for the intranet site and sends it across the Opt link for the MPLS.

              soooooo. the question is: how exactly does squid affect routing?  and is this as simple as setting as adding a route?

              thanks guys,
              -p

              1 Reply Last reply Reply Quote 0
              • P
                plunger
                last edited by

                oh, sweet mercy…

                it was that easy.  hmmm, some clarification for posterity:

                despite the firewall rule that i had in place passing traffic out the proper interface (which was not the default route for the system) squid or something about the way it handles traffic (forgive me, i'm not clear on the specifics) still needed a static route to work properly.

                traffic seems to be flowing nicely from clients on the LAN interface at siteB out the Opt interface, across our MPLS to the web server on it's private ip at SiteA.

                thanks all for pointing me in the right direction.

                with my users happily browsing their intranet, i think i'm going to punch out and go have a beer.

                cheers!
                -p

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