[squid-users] External nat'ed transparent proxy

Matus UHLAR - fantomas uhlar at fantomas.sk
Fri Sep 30 10:36:42 UTC 2016


On 29.09.16 16:39, Henry Paulissen wrote:
>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]

this is a bad configuration. The firewall in the path should NOT use DNAT,
since it makes the important part of connection (destination IP) invisible
to squid.

>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.

not replaced, but renamed.

A "transparent proxy" is a proxy that does not modify the request or
response beyond what is required for proxy authentication and
identification.

An intercepting proxy is a proxy that intercepts request sent to other
server and handles it by itself.

otherwise the functionality is the same (just better) with intercept.
tproxy is intercepting in special mode, so the connection comes from the
client's instead of proxy server's IP address.

>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).
>
>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.

if you really need to intercept users' requests, your network architecture
should be able to do it.

>Is there still a option to emulate normal 'regularĀ“ style squid (as
>without any listen options) but instead accepting the URI path in the
>GET request and looking at the Host header for the destination? (lets
>call it passthrough mode?).

Have you tried configuring WPAD?

>Or, is there in squid3 a new and better way to facilitate larger setups,
>with the knowledge the server, firewall and squids are all in different
>vlans (and no, we dont have Cisco firewalls in between them ;-)).

I am not sure whether it's a good design to intercept requests on one router
and direct them through multiple routers/firewalls.

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Enter any 12-digit prime number to continue.


More information about the squid-users mailing list