Re: [squid-users] Squid 3.1.1 ICAP Issue

>
> Am 13.04.2010 um 12:05 schrieb guest01:
>
>> Hi guys,
>>
>> I may have found a bug related to the ICAP capabilities of Squid 3.1.1
>> (on RHEL5.4). We are currently evaluating a squid deployment which is
>> referenced by this url [1].
>>
>> We want to use Squid as Caching/Authentication-Proxy and ICAP Client,
>> which talks to the Webwasher-server (content filtering proxy) via
>> ICAP. Our Squid has following ICAP configuration:
>>
>> #icap
>> icap_enable on
>> icap_send_client_ip on
>> icap_send_client_username on
>> icap_preview_enable on
>> icap_preview_size 30
>> icap_client_username_encode on
>> icap_client_username_header X-Authenticated-User
>> icap_service service_req reqmod_precache bypass=0
>> icap://yyy.yyy.yyy.21:1344/wwreqmod
>> adaptation_access service_req allow all
>> icap_service service_resp respmod_precache bypass=0
>> icap://yyy.yyy.yyy.21:1344/wwrespmod
>> adaptation_access service_resp allow all
>>
>> (Unfortunately, we can only specify one ICAP server per Squid, but
>> that's another issue/limitation)
>> This deployment is supported by McAfee (Webwasher) and there is even
>> an example configuration[2] for squid and documents for configuring
>> the webwasher by McAfee.
>>
>> ICAP reqmod looks good, everything as expected:
>> Host: yyy.yyy.yyy.21:1344
>> Date: Mon, 12 Apr 2010 10:54:27 GMT
>> Proxy-Authorization: NTLM <BASE64 STRING>
>> Encapsulated: req-hdr=0, null-body=184
>> Preview: 0
>> Allow: 204
>> X-Client-IP: bbb.bbb.bbb.71
>> X-Authenticated-User: <BASE64 encoded USERNAME>
>>
>> GET / HTTP/1.1
>> Host: www.playboy.com
>> Accept: text/html, text/plain
>>
>> ICAP/1.0 200 OK
>> Encapsulated: res-hdr=0, res-body=170
>> ISTAG: "001-000-000003"
>> X-Attribute: sx
>> X-ICAP-Profile: PoC_Policy_TEST
>> X-WWBlockResult: 10
>> X-WWRepScore: 11
>>
>> HTTP/1.1 403 Forbidden
>> Content-Length: 1480
>> Content-Type: text/html; charset=ISO-8859-1
>> Pragma: no-cache
>> Proxy-Connection: close
>> X-Error-Name: requestdynablocked
>>
>> In that case we were assigned to PoC_Policy_TEST and the request to
>> www.playboy.com was blocked. (It seems that we are not supposed to see
>> nice girls at work ;-))
>>
>> If we want to serve to a page which is not blocked (e.g. google.com),
>> we get following request:
>> ICAP/1.0 200 OK
>> Encapsulated: res-hdr=0, res-body=166
>> ISTAG: "001-000-000003"
>> X-ICAP-Profile: default
>> X-WWBlockResult: 81
>> X-WWRepScore: 0
>>
>> HTTP/1.1 403 Forbidden
>> Content-Length: 1279
>> Content-Type: text/html; charset=ISO-8859-1
>> Pragma: no-cache
>> Proxy-Connection: close
>> X-Error-Name: authorizedonly
>>
>> And there is the problem. The ICAP respmod (3.1.1) request does NOT
>> contain the X-Client-IP: bbb.bbb.bbb.71 and X-Authenticated-User:
>> <BASE64 encoded USERNAME> values and that's why the webwasher cannot
>> assign the right policy!
>>
>> If we are using squid 3.0, it works. So in my opinion, this sound like
>> a bug. Right? Has anyboy experiences with ICAP or ICAP issues with
>> Squid 3.1.1?
>>
>> Anyway, besides that problem which I solved by using squid 3.0, there
>> are a couple of other limitation which I don't really want to
>> implement, but I don't see any other change, do you? ;-) At least it
>> does not sound very complicated to implement in c++ ...
>> - possibility to specify more than one ICAP server for a Squid
>> configuration (for example with round robin load balancing or any
>> other kind of loadbalancing)
>> - the much bigger issue is, that Squid as ICAP client does NOT send
>> any group information to the ICAP server, only X-Client-IP and
>> X-Authenticated-User values and no X-Authenticated-Groups attribute.
>> Unfortunately, a policy will be assigned by a group membership. That's
>> why the ICAP server needs that information and it is not a good idea
>> to let the ICAP server lookup this user again (huge performance
>> issue).
>>
>> So, this is quite a long mail, I would appreciate any feedback.
>>
>> best regards
>> Peter
>>
>> [1] http://img714.imageshack.us/img714/7457/topology.png
>> [2] http://wiki.squid-cache.org/ConfigExamples/Webwasher (they are
>> using a proxy chain instead of a icap solution)
>

You?
http://bugs.squid-cache.org/show_bug.cgi?id=2903

Michael Portz wrote:
> Did you use the
>
> follow_x_forwarded_for
>
> option in your squid.conf? (Doc for example to be found here)
>

That is only needed if the client IP is being located inside the XFF header.
The icap_send_client_ip setting already turned on should have been
adding X-Client-IP with at least the directly connected requestor IP
regardless of XFF.

For some strange reason the client_addr seem to be empty in the HTTP
request details used to construct the ICAP request.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.1