Re: ICP proxy for Firewall

Many thanks for all the replies on the ICP proxy issue.

> From: Jonathan.Larmour@uk.origin-it.com
> Sent: 21/10/97 13:48
>>From: Marc van Selm
>>Sent: 21 October 1997 08:31
>>To: tgraff@esoc.esa.de; squid-users@nlanr.net
>>At 06:50 PM 10/20/97 +0200, tgraff@esoc.esa.de wrote:
>>
>>This might be very useful but TIS told us UDP is not something they want
to
>>support. It is possible to set up a "UDP-tunnel" though the FW "but
people
>>who do this will get on the black list" (Quote from one of the tech's who

>>came to set up an initial evaluation system) The main problem (their main

>>problem) was that they couldn't keep a good Connection-state. (I think
this
>>should be possible but requires understanding of the Higher layer
protocol
>>completed with time-outs)

Yes, this matches the reply from TIS I've received in the meantime. I also
don't
like the ideal of a UDP FW bypass for the ICP.

>[] The point with UDP is in fact that it is connectionless, i.e. there is
no
>connection to know the state of! There are programs that can do this
(udprelay)
>but only to one specific host (although you could use different UDP ports
on
>the firewall to do different hosts). In practice, this isn't really the
>way to go.

Also the so called "plug-gateway" solution for different host seems to be
too
static.

>>
>>4) Have an internal proxy which takes care of the "routing"

>This sounds like the best approach to me. However I would have it the
other
>way round to what you imply, and have the real "big" proxy on the inside,

>and just a little squid on the outside to field the ICP. This little squid

>would be "default no-query". The reason is that the more traffic that
passes
>through the firewall, the more stuff is parsed by the firewall software
>(http-gw?), and this has to be done for every request, even the cached
ones.
>
>So it is much quicker for the user if it is done this way round.
>
>Jonathan L.
>

I think this will be the way I'll take for our scenario here, although this
implies some extra cost for a second machine and we have then three points
of
failure (the two caches and the FW, through which all non local cached
requests will be passed). But the good thing: this will also take some load

form outr FW http-gw.
The question I have now is: will this external "routing" cache require to
be a
powerfull machine? Well, it will not do any caching (the internal big one
will
do this). But has to handle all outgoing http requests. So there will be
quite
some squid and dnsserver daemons running. Will there be very high CPU load,
 or
will a mid-range desktop workstation or PC be sufficient? (we have ~500
users
on our site). Any experiences?

Many thanks,

---
European Space Operations Centre
phone: (+49)-6151-90-2996
FAX: (+49)-6151-90-3503
Email: tgraff@esoc.esa.de