On 2013-06-01 23:57, Rob Sheldon wrote:
Assuming I can get this all working somehow, I'll do a solid write-up
of it on our company site. Was the security check added in a sort-of
recent version of Squid? I still find it hard to believe that this has
been broken for other people and gone unreported or that I'm the first
person recently to try to get Squid working on OpenBSD ... I'm still
expecting to find that I'm doing something wrong.
To answer my own question: the additional security check in Squid,
which is incompatible with rdr-to, was added in Squid 3.2:
http://www.squid-cache.org/mail-archive/squid-users/201208/0374.html
...which is new to OpenBSD 5.3, released just a month ago. OpenBSD 5.2
used Squid 2.7, which did not include this check.
So every piece of how-to documentation on the web for setting up Squid
on OpenBSD is now wrong.
Or, OpenBSD (and presumably FreeBSD) users will need to stick with 2.7
(still available as a separate package in OpenBSD 5.3).
I'm curious how the Linux guys deal with this. I don't have a
multi-interface Linux machine handy, or I'd test.
...Oh. The current Squid package available for the most recent version
of Debian (I'm on the testing branch, so this is up-to-the-day current)
is also 2.7.
Yucky.
I'm willing to sink some time into trying to get 3.2 up and running in
a best-recommended fashion on OpenBSD and then writing a howto for it,
if other people are willing to contribute suggestions. According to
Amos' post at the link above, it sounds like Squid does some kind of nat
of its own? I don't quite understand this. If so, does it maintain its
own state table? Is there any risk of things like mixed-up web sessions?
I implicitly trust pf's handling of nat and state; I'm a little
squeamish about letting something else take over a portion of that.
Thanks,
- R.
--
[__ Robert Sheldon
[__ No Problem
[__ Information technology support and services
[__ (530) 575-0278
