Good morning Eliezer, It took some time for me to construct a drawing who would be understandable enough how our setup is, as the diagrams you provided didn't fully fit the case. But, I think I managed to make a understandable drawing of it :-) [ Link to PNG image ] https://drive.google.com/file/d/0BysciyDBahUtWU55RjNPUlFjMTQ/view Some additional info with the drwaing: - Each linux firewall server handles top ~5G traffic. After that we build a new firewall cluster and new servers are connected to that one. - The linux firewall is gateway for the vlan. - As you might know: LVS is internally also a DNAT, so bassicly we do a double DNAT. - The green and blue line indicates how the traffic is routed - Linux firewalls is physical hardware, but all the servers (including the squid hosts) are linux vservers (like LXC containers or docker containers). Hopes this clears up our setup and where I run into problems with squid3. Regards, -- Henry Paulissen - PD0OM henry@xxxxxxxxxxxxxxxx - Phone: +31-(0)6-115.305.64 Linux/Unix System Engineer On 30-09-16 00:35, 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. > 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? > Also, if you have not used tproxy and intercept on the PROXY machine you should re-think the whole logic of the system first before deciding on the next step. > There are systems which needs redesign when moving from Squid 2 to 3 or 4. > When I and you will have the right understanding of the scenario I believe we can find the right path if this is not already there. > > Let me know if these( the diagrams..): > http://wiki.squid-cache.org/EliezerCroitoru/Drafts/MwanLB#Intoduction_to_MultiWAN_LoadBalancing > http://wiki.squid-cache.org/ConfigExamples/UbuntuTproxy4Wccp2 > > Make any sense to you so we can find the right words to fill the gaps in the situation. > Once I will have the right picture I would probably have enough information to draw some picture in VISIO and move forward to the Systems table. > > Eliezer > > ---- > Eliezer Croitoru > Linux System Administrator > Mobile+WhatsApp: +972-5-28704261 > Email: eliezer@xxxxxxxxxxxx > > > -----Original Message----- > From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Henry Paulissen > Sent: Thursday, September 29, 2016 5:40 PM > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: External nat'ed transparent proxy > > 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). > > 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. > > > 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?). > > 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 ;-)). > > > Thanks in advance, > > -- > Henry Paulissen - PD0OM > henry@xxxxxxxxxxxxxxxx - Phone: +31-(0)6-115.305.64 Linux/Unix System Engineer > >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
