Re: [squid-users] Re: NetfilterInterception: NF getsockopt(SO_ORIGINAL_DST) failed on FD 4125: (2) No such file or directory

From: Amos Jeffries <>
Date: Sat, 12 Oct 2013 14:33:24 +1300

On 12/10/2013 4:48 a.m., Omid Kosari wrote:
> Amos Jeffries-2 wrote
>> Would your proxy happen to be receiving the inbound traffic to
>> port 80 ?
> Let answer like this . is one of our customers . customers dst
> port 80 will be routed to squid except if dst address is another customer .
> so if wants access it goes to squid . but if clients
> wants to open it does not goes through squid and vice versa .
> Another thing i did not investigate a lot but when i removed 302: from
> jesred.rules the redirection does not work and browser waits several minutes
> for response .

Okay. Those rules are being applied to all your customers traffic. Not
just the netshar traffic. So non-netshar customers would be redirected
to and then your proxy. You may need to add extra src
ACL test to restrict the clients who get the redirect applied - which is
true whether you keep using jesred or siwtch to the squid-only option below.

This is how you do the exact same thing with only Squid instead of using

    acl domains_to_redirect dstdomain "/etc/squid3/to_redirect_program.acl"
    acl netshar_regex url_regex "/etc/squid3/netshar_regex.acl"
    deny_info 302: netshar_regex
    adapted_http_access deny domains_to_redirect redirect_regex

/etc/squid3/netshar_regex.acl contiains the regex patterns being checked
by jesred:


If you need any other redirect destinations you can create other *_regex
ACL and deny_info pairs. Or in the later squid versions use deny_info
pattern substitution to generate the redirect URL

> Amos Jeffries-2 wrote
>> I mean a new line above them:
>> http_port 12345
>> or whatever you like for the port value. It does not have to be used,
>> but will help prevent traffic going to the interception ports when it
>> was not intercepted.
> ok got it . i changed it to following lines .
> http_port 3127 intercept
> http_port 3128
> http_port 3129 tproxy
> after that following appears in headers
> X-Cache MISS from
> X-Cache-Lookup MISS from
> Via 1.0 (squid)
> is the X-Cache-Lookup line ok ? it should show 3127 ?!

This is why I said put the forward-proxy port at the top of the list.
3.1 does not filter out intercept/tproxy ports when it generates those
host:port details. It just uses the first http_port value.
The idea is to hide the intercept/tproxy port details from any possible
kind of external connection directly to them.

> Amos Jeffries-2 wrote
>> Okay. The ORIGINAL_DST security checks are not present in 3.1, so the
>> NAT error is a non-fatal event for you at the moment. If it is
>> encountered by a 3.2 or later proxy it is a transaction blocking event.
>> In 3.1 the NAT lookup is rather strangely done after parsing each HTTP
>> request, even on persistent connections, so it may just be something
>> related to NAT table entries expiring while buffered requests are
>> processed. Or the NAT system being overloaded with useless lookups on a
>> heavily loaded machine - both those should be kind of rare though.
> But it is fatal event for my network :)
> root_at_cache:~# echo $( cat /proc/sys/net/netfilter/nf_conntrack_count ) / $(
> cat /proc/sys/net/netfilter/nf_conntrack_max )
> 351452 / 524288
> root_at_cache:~# grep conntrack /proc/slabinfo | awk '{ SUM += $3 * $4 } END {
> print SUM / 1024 / 1024 " MB" }'
> 109.316 MB
> Can you guide me to NOTRACK usefulness conntracks ? for example may i safely
> notrack htcp traffic between 2 squid boxes ? what kind of other traffics ? i
> hate try and false in production .

conntrack is required for tracking the NAT and TPROXY translations.
You can use it on other traffic, but not on that going to the proxy.

NP: If you have stopped tracking for inbound connections to the proxy it
would probably generate this ORIGINAL_DST error message.

> As i said in first post this problem appears after those 3 changes .
> problems with nat existed before but this problem appears recently . BTW i
> need help to clears unused conntrack .
> If you say i can try to upgrade my squid package from
> .
> Amos Jeffries-2 wrote
>> It would be worth it for testing this problem at least. If requests were
>> being looped through the proxy twice having it on will produce a warning
>> message.
> Via turned on sir . but one question . how loop may occur ?

The simplest one is:

  GET HTTP/1.1


  GET / HTTP/1.1
  Host: localhost:3127

client--(squid:3127)-> Squid --(squid:3127)-> Squid <== loop with 2x
NAT lookup error!

Or the NAT/TPROXY rules being configured to turn outbound traffic
leaving your proxy back at at itself:

client --(> NAT--(squid:3127)-> Squid -> NAT
--(squid:3127)-> Squid <== loop!

client --(> TPROXY --(squid:3129)-> Squid -> NAT
--(squid:3127)-> Squid <== loop!

client --(> TPROXY --(squid:3129)-> Squid -> TPROXY
--(squid:3129)-> Squid <== loop!

  client --(> NAT--(squid:3127-> Squid -> TPROXY
--(squid:3129)-> Squid <== loop!

Received on Sat Oct 12 2013 - 01:33:34 MDT

This archive was generated by hypermail 2.2.0 : Sun Oct 13 2013 - 12:00:05 MDT