Re: [squid-users] external NAT and "Protocol not available"

Hi Amos,

On 01/07/11 06:22, Amos Jeffries wrote:
> 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.
>

I thought I did?

>> :
>> http_port 3128
>> http_port 3129 intercept
>> :

What exactly do you mean by "direct" connections? Is this
the traditional proxy setup explicitly configured in the
http client? AFAICS no local client in my $lan is configured
in this way. I would like to have transparent mode only.

> 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.
>

If I got you correctly this means that the HTTP header
information cannot be trusted, but Squid does, because
asking the packet filter for the "real" destination
of the HTTP access failed?

Would you suggest to run Squid on the OpenBSD gateway
instead to make sure that communication between Squid
and Packet Filter works?

Where does squid get the "real" destination _port_ from?

Here is my OpenBSD packet filter code redirecting/natting the
traffic from the http client to the squid host:

+---------------+ +----------------------+
| http client | | squid proxy (Linux) |
+-------+-------+ +-------+--------------+
        | |
        | |
   lan +---------------------------+
        |
        | int_if1
+-------+-----------+
| OpenBSD gateway |
+-------+-----------+
        | ext_if
        |
        :
          internet

:
http_ports = "{ http, 8080 }"
http_proxy = "10.10.10.50"
http_proxy_port = "3129"
:
:
no rdr on $int_if proto tcp from $http_proxy port $http_ports
rdr on $int_if proto tcp from <use_proxy> to !$lan port $http_ports tag LAN_HTTP_PROXY -> $http_proxy port $http_proxy_port
no nat on $int_if proto tcp from $int_if to $lan
nat on $int_if proto tcp tagged LAN_HTTP_PROXY -> $int_if1:0
:
:
pass quick tagged LAN_HTTP_PROXY
:

The redirection rule assigns a tag "LAN_HTTP_PROXY" and
forwards the http traffic from $lan to the squid proxy.
The nat rule makes sure that this traffic seems to come
from the gateway, so squid won't talk with the http client
directly. The pass rule allows the tagged traffic to pass.

The squid host's outgoing http traffic to the internet is
natted as usual:

ext_tcp_ports = "{ http, 8080 }"
:
:
nat on $ext_if tag LAN_INET_NATTED tagged LAN_INET -> $ext_if:0
:
:
pass out quick tagged LAN_INET_NATTED
pass in inet proto tcp from $lan to !$lan port $ext_tcp_ports tag LAN_INET

Logging is not shown here.

Surely I have not that much experience in writing packet filter
files. Any helpful comment would be highly appreciated.

Regards

Harri
Received on Fri Jan 07 2011 - 10:26:14 MST