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

On 07/01/11 23:26, Harald Dunkel wrote:
> 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?

Ah, I see from the details you provide below, you got the Squid part
right but have problems in the overall network setup. Help below...

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

Yes, I mean the connections from browsers or other agents which are
configured and aware that they are talking to a proxy.

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

No, the TCP-level information cannot be trusted. It's provided by the
local kernels NAT table, which is saying to Squid the request did not
arrive via NAT. The HTTP-level headers have a very slightly higher
trustability level (though still not great).

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

Squid MUST run on the same box performing NAT for any kind of security.

I'm not very familiar with the firewall you are using. In concept we
mark the packets from client IPs to port 80 for special handling by the
routing. Then route the marked packets to the Squid box unchanged and
non-marked out to their Internet destination. So the squid box is a
special gateway for port 80 traffic only.
  Then do NAT on the Squid box to redirect port 80 client packets into
Squid.
  Outbound traffic from Squid to the Internet goes back to the router as
normal and through the NAT there. The marking rule needs to bypass when
source IP is the Squid box.

I'm not familiar with PF so can't spec the rues for you. I hope this
process explanation is enough to help you.

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

The local kernels internal NAT table. Along with the real destination IP.

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

Squid hard-configured with the OpenBSD as the only gateway to its local
network instead of straight to the clients should fix that issue.

Or having the proxy configured such that it is on its own subnet inside
the larger client LAN subnet may also work (though more complex in the
router).

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

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.10
   Beta testers wanted for 3.2.0.4