Hey, As Amos suggested you should use Policy based routing and not DNAT. The main reason for that is since it's breaking the Interception layer which squid relies on for fallback scenarios.
I can write the logic for this pretty fast but you should first understand that your setup is wrong in a way. Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: elie...@ngtech.co.il -----Original Message----- From: Henry Paulissen [mailto:he...@nitronetworks.nl] Sent: Friday, September 30, 2016 12:48 To: Eliezer Croitoru <elie...@ngtech.co.il> Cc: squid-users@lists.squid-cache.org Subject: Re: [squid-users] External nat'ed transparent proxy 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 he...@nitronetworks.nl - 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: elie...@ngtech.co.il > > > -----Original Message----- > From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] > On Behalf Of Henry Paulissen > Sent: Thursday, September 29, 2016 5:40 PM > To: squid-users@lists.squid-cache.org > Subject: [squid-users] 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 > he...@nitronetworks.nl - Phone: +31-(0)6-115.305.64 Linux/Unix System > Engineer > > _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
