[squid-users] Unable to IPv6 DNAT & intercept (Debian Stretch, Linux 3.16.0, Squid 3.5.19)

[Amos Jeffries]

On 10/06/2016 3:48 a.m., Joni Kähärä wrote:
> Hello list,
> 
> I'm approaching you with a question regarding intercept proxying and IPv6.
> I have a working IPv4 setup that redirects port 80 traffic to a port that
> Squid is listening on:
> 
>     -A PREROUTING -s <source-net> -p tcp -m tcp --dport 80 -j REDIRECT
> --to-ports <squid-port>
> 
> When I try to duplicate this behaviour on IPv6 side, it does not work. This
> does not seem to be an ACL issue as the symptoms are the same even with an
> all-allowing ACL, and because I'm unable to get even an "access denied"
> error from Squid. I can reach the IPv6 Squid port by accessing it directly
> from the local machine.
> 
> Also, if the REDIRECT is changed to a DNAT, the behaviour is identical
> (i.e. not working):
> 
>     -A PREROUTING -s <source-net> -p tcp -m tcp --dport 80 -j DNAT
> --to-destination [<squid-ip>]:<squid-port>
> 
> By looking at ip6tables packet counters and tcpdump I have come to a
> conclusion that a SYN packet hits the REDIRECT rule, but even if it ever
> reaches Squid, it looks as if Squid is ignoring it and not returning
> anything. Enabling debug sections 5 and 89 show nothing in cache.log while
> the connection establishment is supposed to be happening. While trying to

Then the issue is in the kernel. That debug level always produces
output, starting with the NAT-mangled IP:port details given by the
accept(2) syscall triggered by SYN arrival.

If the kernel IPv6 NAT is not resulting in an accept(2) operation
something is buggy in the TCP stack.

Double-check that libcap-dev was used when Squid was built. That
rpfilter, SELinux, Apparmor etc. are not blocking the activity.

Amos