[squid-users] Re: Port based ACLs for Squid setup with upstream proxying to Surfingate's Finjan-

Joost:

Thank you- I tested this out, and it certainly does clean up the ACLs
considerably. Unfortunately it doesn't solve my original problem, but
thats not the fault of the ACLs - rather the way that windows media
player seems to handle multiple proxies. This sequence of events is
confirmed by ethereal:

1. Windows Media Player (WMP) requests a radio stream, which is itself a
three-part process.
2. The first part of the process is WMP requesting ads/commercials -
these requests match the http protocol and port 80 ACLs, and so they are
punted to FinJAN.
3. Finjan handles these requests, and the replies are sent back to WMP
via Squid. It is important to note here that our firewall uses Port
Address Translation (or PAT) from a group of public IPs, and so the
external request from Finjan might appear to come from 1.2.3.5
4. The ads/commercials play, and sound is heard.
5. The second part of the process is WMP requests the media stream,
some/most of the time from a different website than the ads.
6. These requests match the WMP and "req_mime_type" ACLs that Chris
Roberston suggested in an alternate part of this thread, and so Squid
handles these requests directly.
7. Since Squid is a separate box (with external access equal to or above
that of FinJAN), PAT kicks in again for the external request, and this
request appears to come from 1.2.3.10
8. This stream does NOT play.
9. The third part of the process is that WMP assumes that the stream is
playing properly, and it makes requests for ads and commercials in the
background. Since these requests ALSO match the http proto/port 80 ACL,
they are handled through FinJAN.

This is verified by the fact that the squid ACLs that you guys suggested
actually work properly. As I mentioned before, I tested this out with
FTP and a few IM apps, and any non-http-protocol/non-port-80 traffic
gets handled by squid directly.
Also, any radio station that supports http-proxy streams (like
club977.com) seem to work just fine.

The reason WMP works on PCs that match the IP based ACLs is because
Squid handles ALL traffic (http protocol traffic included) for these
IPs. In turn, WMP sees both the ad requests and the stream requests as
coming from the same 'public' IP address.
I verified this as well - by changing the policy for the IP based ACL
PCs to use FinJAN for http-protocol traffic. Instantly breaks WMP
non-http-protocol radio stations.

Which leads me to believe that the way in which these radio stations
offer "free" streams is to essentially require that the request for the
radio and the request for the ads come from the same 'public' ip. For
webradio stations that offer http-proxy support, this seems to be a
non-event.

In other words, I think this has ceased to be a squid configuration
issue - at least in the sense that the ultimate solution is not going to
be ACL based.
I considered the alternate option - running two squid processes on the
same box - and rejected that as well, because it would be a trivial
process for a user to change their browser proxy settings and channel
all of their traffic to the second 'fully open' squid process to avoid
FinJAN and effectively bypass the corporate policy.

I believe there really are only two solutions left:
1. To open up tcp 1755/ udp 7000-7007 on the corporate firewall
2. To change the external NAT/PAT policy and ensure that both Squid and
FinJAN use the exact same public IP address.

The last two paragraphs are just really for archival purposes - for
anyone browsing this thread in the future.

Thank you all - specifically both you and Chris - for your suggestions.

---Maxx

On Thu, 2005-02-10 at 04:37, Joost de Heer wrote:
> > What I would like to know/do:
> > -----------------------------
> > Is it possible to use the cache_peer directive to pass all port 80/443
> > traffic to FinJAN, and process all other 'Safe_Ports' traffic locally
> > through Squid?
>
> Not tested:
>
> cache_peer peer1.domain parent [options]
> acl http-proto proto http https
> cache_peer_access peer1.domain allow http-proto
> never_direct allow http-proto
> always_direct allow !http-proto
Received on Thu Feb 10 2005 - 19:07:42 MST