On 05/01/11 02:09, Harald Dunkel wrote:
Hi folks,
I've got an OpenBSD gateway (including NAT) redirecting HTTP
traffic to a dedicated internal Linux host running Squid 3.1.9.
Problem: I see tons of messages in cache.log
:
2011/01/04 11:03:38| IpIntercept.cc(137) NetfilterInterception: NF getsockopt(SO_ORIGINAL_DST) failed on FD 12: (92) Protocol not available
2011/01/04 11:03:38| IpIntercept.cc(137) NetfilterInterception: NF getsockopt(SO_ORIGINAL_DST) failed on FD 21: (92) Protocol not available
2011/01/04 11:03:45| IpIntercept.cc(137) NetfilterInterception: NF getsockopt(SO_ORIGINAL_DST) failed on FD 10: (92) Protocol not available
2011/01/04 11:03:47| IpIntercept.cc(137) NetfilterInterception: NF getsockopt(SO_ORIGINAL_DST) failed on FD 28: (92) Protocol not available
:
Web access doesn't seem to be affected. How can I tell squid
to shut up?
The fix for all of this is to use separate ports for direct
client->proxy connections and for NAT intercepted traffic.
What Squid is complaining about is that it can find no information about
the real source of that traffic.
On top of the NAT problems, when Squid receives forward-proxy traffic
through a NAT interception (aka transparent) port your proxy is open to
the CVE-2009-0801 forging attack which permits one infected client to
infect an entire network.
Google recommended on the mailing list to use a dedicated
intercept address, but this did not help. Here is the
squid.conf file:
Did you remember to update the iptables rules to match this change?
If this *was* all NAT intercepted traffic your logs for these requests
contain false client IPs and your server is very likely also
mis-directing or dropping client packets based on wrong/missing NAT records.
http_access allow all
This is really, really dangerous.
At a minimum spec out the networks which are your clients and permit
from only those IP ranges.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.10
Beta testers wanted for 3.2.0.4
