[squid-users] External nat'ed transparent proxy

[Henry Paulissen]

Hi Matus,


On 30-09-16 12:36, Matus UHLAR - fantomas wrote:
> 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.
> 

That is where the HTTP Host header can be used for... For squid to
figure out the destination of the request. (aren´t they?)

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

Sorry, this is a discussion about the definition about what a
transparent proxy is and what is not. I dont feel the need for this to
discuss at the moment (no hard feelings, but it doesn't aid to the
problem i`m facing).


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

Our network architecture is able to do it, otherwise it wouldn't
currently work.

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

Linux (shell) servers dont do 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.
> 

The whole idea about intercepting is that we delivered environments in
the past (10+ years) who didn't had to be configured to use a proxy.
Whatever this was a good thing to do or not is not within my power to
change anymore.
Back then, SSL wasn't a thing yet. So nobody thought about it.

In my reply to Eliezer Croitoru is a network diagram included.
Maybe this can shed a light onto our network topology.


-- 
Henry Paulissen - PD0OM
henry at nitronetworks.nl - Phone: +31-(0)6-115.305.64
Linux/Unix System Engineer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160930/860803e3/attachment.sig>