[squid-users] squid "internal?" loop - with no firewall nat going on..?

[Amos Jeffries]

If your intention here is to get around a broken firewall devices port
80/443 inspection then I expect you require two proxies anyway. The
traffic has to be on a different port entirely which is not being
mangled by the firewall.

One before and one after the firewall, with packets flowing over the
unusual port between them.

Otherwise the traffic will still be going through the firewall on port
80/443 regardless of the proxying.

The proxy closest to the clients should be doing the NAT intercept,
pasing traffic explicitly to the one outside, and the one outside being
a normal forward-proxy accepting traffic only from the internal one.




On 12/03/2015 10:11 p.m., Klavs Klavsen wrote:
> As i Understand intercept - that will only work (as you said) when NAT
> is performed on the box that is to intercept (when I remove haproxy -
> that means the squid box itself).
> 
> and I'm going to move the squid box to the same network as the
> webservers - to be able to do it the routing way.
> 
> It seems this config should then be applicable "When Squid is in a DMZ
> between the router and Internet" from
> http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute
> 
> But do I need to enable net.ipv4.ip_forward = 1 ?
> But perhaps that is needed, for iptables/linux kernel to even evaluate
> PREROUTING rules (which then dnat's the package into squid port 3129)?

Yes, in order to receive packets destined for machines other than itself
forwarding is required. Otherwise the TCP stack martian packet detection
kicks in and drops them as invalid.

> 
> I'd like to only allow packages out of the box, when coming from squid
> (in case of some config issue - I'd like the squid-server NOT to route
> stuff, which didn't go through squid program).
> 
> and then I figured I'd could ensure that from happening, by adding:
> iptables -t nat -A OUTPUT --match owner --uid-owner squid -p tcp --dport
> 80 -j ACCEPT
> iptables -t nat -A OUTPUT --match owner --uid-owner squid -p tcp --dport
> 80 -j ACCEPT
> 
> and then ofcourse allow "state RELATED,ESTABLISHED" and traffic I
> actually "want" and have default policy DROP.


I dont think the NAT table is the right place to be doing that.

You need the NAT table rules from here
<http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat>

The mangle PREROUTING rule protects against external abuse of the Squid
port.
The nat PREROUNTING rules are to get packets into Squid (or bypass).

The nat POSTROUTING to ensure that all packets bypassed or Squid outputs
all come back through this machine.

To prevent packets going through the machine without going through Squid
add rules in the fiter table FORWARD chain.

Here is the netfilter packet flow diagram:
<http://inai.de/images/nf-packet-flow.svg>
(Squid would be the "local process" at the top center.)


> 
> Klavs Klavsen wrote on 03/12/2015 09:13 AM:
>> Hi Amos,
>>
>> Thank you for the walkthrough..
>>
>> Instead of having to play with tproxy on haproxy currently, I figured
>> i'd try a simpler route..
>>
>> The purpose of this setup, is to "jump around" a firewall issue with a
>> sh#! firewall, which in order to filter http and https traffic
>> appearently drops 5-15%.. and in 6 months noone has seem willing/able to
>> fix it :(
>>
>> I've put squid directly on the 10.43.18.181 (previously haproxy) ip -
>> and changed to: http_port 80 intercept
>>
>> I tried this on the client (being on other subnet):
>> iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination
>> 10.43.18.181:80
>>
>> and the traffic looped in exactly the same way :(

OUTPUT is catching all traffic leaving processes running on the Squid
machine, including from Squid itself.

Amos