Squid/squidguard blocking port 80 to private(RFC 1918) ips
-
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 -
<crickets>sigh</crickets>
-
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.
-
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 -
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 -
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