[squid-users] getsockopt failures, although direct access to intercept ports is blocked

[Amos Jeffries]

On 24/02/22 12:05, Andreas Weigel wrote:
> Hi everyone,
> 
> I had the following issue with Squid in Transparent Mode (and SSL 
> Interception in mode splice). It is working as expected, however after 
> multiple long-running (talking about several seconds) anti-virus 
> ecap-Processes have finished, I *sometimes* get the following in the log:
> 
> 2022/02/23 14:56:40.668 kid1| 5,2| src/comm/TcpAcceptor.cc(224) 
> doAccept: New connection on FD 21
> 2022/02/23 14:56:40.668 kid1| 5,2| src/comm/TcpAcceptor.cc(312) 
> acceptNext: connection on local=[::]:2412 remote=[::] FD 21 flags=41
> 2022/02/23 14:56:40.668 kid1| 89,5| src/ip/Intercept.cc(405) Lookup: 
> address BEGIN: me/client= 192.168.180.1:2412, destination/me= 
> 192.168.180.10:48582
> 2022/02/23 14:56:40.668 kid1| ERROR: NF getsockopt(ORIGINAL_DST) failed 
> on local=192.168.180.1:2412 remote=192.168.180.10:48582 FD 37 flags=33: 
> (2) No such file or directory
> 2022/02/23 14:56:40.669 kid1| 89,9| src/ip/Intercept.cc(151) 
> NetfilterInterception: address: local=192.168.180.1:2412 
> remote=192.168.180.10:48582 FD 37 flags=33
> 2022/02/23 14:56:40.669 kid1| ERROR: NAT/TPROXY lookup failed to locate 
> original IPs on local=192.168.180.1:2412 remote=192.168.180.10:48582 FD 
> 37 flags=33


These can happen if the NAT table entries expire or otherwise get 
dropped by conntrack between the client initiating TCP SYN and Squid 
accept(2) receiving the connection.

Your config looks good to me and the lack of regularity indicates the 
issue is likely this type of transient state situation.
  Is this happening at times of unusually high client connections 
through the NAT?
  Is eCAP processing blocking the Squid worker for all those seconds?


> 2022/02/23 14:56:40.669 kid1| 5,5| src/comm/TcpAcceptor.cc(287) 
> acceptOne: non-recoverable error: FD 21, [::] [ job2] handler 
> Subscription: 0x55edac3d08d0*1
> 
> Sometimes, this only appears on on of the two interception ports, 
> sometimes on both. After that, the squid worker does not poll the 
> intercept listen port any longer, i.e. stops working.

That part is likely to be the issue recently worked around by 
<http://www.squid-cache.org/Versions/v6/changesets/squid-6-9fd3e68c3d0dfd6035db98ce142cf425be6c5fc1.patch>


Amos