On 21.03.2012 06:27, GarethC wrote:
Hi Peter,
I've seen similar issues with Bluecoat boxes in the past, whereby
Squid
receives requests from the Bluecoats and the Bluecoat IP address
appears in
the logs.
Happens whenever the client is another proxy ;)
I'm guessing your pfSense boxes sit in front of your Squid server?
By default, Squid has 'forwarded_for on' which means it will append
the
source IP (which to Squid is the IP of the pfSense box) to the
X-Forwarded-For header.
This is all for details leaving Squid. Not much use for received
traffic, but could be helpful for any other software you have chained.
You need to change this option to 'forwarded_for transparent', and
ensure
that your pfSense box sets the X-Forwarded-For header.
What this does is tell Squid that you fully trust whatever you receive
in XFF header enough to hide Squid and take responsibility for any
details or lies which the directly connected peer is passing over. See
below.
In your logformat you should also place "%{X-Forwarded-For}>h" so
that the
contents of the header are included in the log file.
... logging the full XFF header details (useful).
Alternatively:
acl peers src <pfsense IP address>
follow_x_forwarded_for allow pfsense
follow_x_forwarded_for deny all
What these follow_* do is tell Squid that you completely trust all
traffic from the peer IP address and allow *the peer* to manipulate
things as security-critical as your squid server logs and what src-IP is
used when processing your http_access rules.
Sounds scary, but it is safe enough if you actually do trust that
peer. Just be careful which peers you "allow"/trust.
Peter,
if you already have the above follow_* rules setup using the IPs your
pfsense use to connect to Squid, then it will be the pfSense boxes
failing to send the XFF header.
Amos
