[squid-users] External nat'ed transparent proxy

[Amos Jeffries]

On 30/09/2016 11:35 a.m., Eliezer Croitoru wrote:
> Hey Henry,
> 
> I want to emulate the setup to understand the complication with a FULL linux based setup here on my local testing grounds.

No need Eliezer. This is the basic NAT re-writing problem.

> Can you give more details on the networks in the form of subnets and VLAN numbers?
> What is not clear to me is: Who is doing the DNAT?

The firewall *outside* the Squid machine.

> 
> -----Original Message-----
> From: Henry Paulissen
> 
> Hi all,
> 
> In the company I work for we are currently using squid v2 proxies in
> transparent mode to intercept traffic from servers to the outside
> (access control).
>
> The technical solution for this is roughly as follows:
> [server] -> [gateway] -> [firewall]
>                               |
>     ----------- DNAT ---------
>    v
> [squid]  -> [gateway] -> [firewall] -> [internet router]
> 
> Our firewalls (who live between the vlan gateway and internet
> router), DNAT the traffic towards separate squid proxies (who are in
> a lvs cluster). These squid proxies are in their own vlan with
> special permissions to allow unrestricted port 80 outbound, etc,
> etc...
> 
> Because squid v2 is becoming more and more obsolete we are looking
> at upgrading it towards squid v3.
> 
> From what I read in the manuals, transparent mode is replaced by 
> intercept (and tproxy) mode. But both dont seem to be fully backward 
> complaint with the v2 transparent mode.
> 
> The old trasparent mode allowed us to just dnat traffic towards the 
> squid host without the need for the client to be aware of this. For 
> example, the old style accepted 'GET / HTTP/1.1' (without full URL
> in the GET request and looking at the Host header for the
> destination).

Sadly. That is incorrect.

Squid-2 used to simply lie to you, silently hiding any attacks that were
happening through the proxy. Whenever NAT on the Squid machine failed to
identify the packet destination it gave Squid false information for the
logs based on the client-supplied Host header DNS results.

> 
> The new intercept mode comes close to this behavior, but instead of 
> remotly dnat, it wants us to next-hop it towards the squid proxy and 
> redirect it locally. This is problematic for us as firewall and
> squid proxy dont live in the same vlan, so next-hop should be the
> router to that vlan (and forgetting about the path back to the
> server). Secondly, and not less blocking, we use vservers
> (predecessor to linux containers lxc) as such, we dont have any
> promiscuous interfaces rights within the container.

Sorry. That is a requirement nowdays. Browser offer a full XHR or Flash
networking stack for use by remotely supplied (ie attacker supplied)
code that can forge requests so we cannot trust the client delivered
Host headers anymore.
NP: This actually makes Squid behave more "transparent" than ever
before, since it now preserves the destination IP.

You have a couple of options;

1) tunneling the packets from the machine which used to do NAT through
to the Squid machine. WCCP, IP-over-IP, GRE, etc.

 The NAT you used to have was just a way to tunnel the packets through
the DMZ subnet to Squid anyway. So this is conceptually no different to
what you have now. The issues which you might associate with tunnels
were already happening, just hidden by the NAT.


2) route the packets from the internal gateway to the squid machine as
if it were another gateway. Conceptually Squid *is* being a gateway for
port 80 traffic.

There are a couple of routing designs detailed at
<http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute>
for setting that up if your gateway machine uses iptables. You might be
able to find equivalent documentation for other OS if you need.

Or you might design your own routing methods. The key thing is that the
destination IP:port numbers cannot be changed on the TCP packets between
the client and Squid.

Amos