Hi, I have a Shorewall multi-ISP gateway/router (host1) and beneath it another shorewall router (host2) with Squid installed on the same box. I also have another Squid server within one of host2''s subnets. Host1 does packet marking via tcrules in order to filter traffic accordingly amongst available ISPs. As an example, mark 1 for all packets coming from 10.215.144.48 and going to 8.8.8.8 will send/receive packets to/from ISP1. Likewise, mark 2 for all packets from 10.215.144.7 will send through ISP2, and so on... That works fine for clients within host2''s subnets that reach the internet via host2+host1 unless there''s a proxy in between. Suppose clients within a host2 subnet are required to use an HTTP proxy such as Squid to browse the web, then host1 will mark all of the packets the same way since they will be originating from the same IP address, the one where the HTTP proxy is at. So host1 won''t be able to mark differently according to the source IP address unless the proxy in host2 (or within a host2 subnet) somehow "spoofs" it''s IP address and impersonates the client''s address. Can an HTTP proxy do that? I also require proxy user authentication via a winbind auth plugin so I can''t use a "transparent proxy" or tproxy, I guess. Would marking packets on host2 (the inner shorewall router) the same way host1 would mark them, be a workaround, provided the Squid proxy is on the same server as shorewall (ie. host2)? That way, I guess that packets would be marked before being handled by Squid on host2 and sent to the Internet via host1. Any ideas? Thanks, Vieri ------------------------------------------------------------------------------ uberSVN''s rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
On Aug 10, 2011, at 10:55 AM, Vieri Di Paola wrote:> I have a Shorewall multi-ISP gateway/router (host1) and beneath it another shorewall router (host2) with Squid installed on the same box. I also have another Squid server within one of host2''s subnets. > > Host1 does packet marking via tcrules in order to filter traffic accordingly amongst available ISPs. > As an example, mark 1 for all packets coming from 10.215.144.48 and going to 8.8.8.8 will send/receive packets to/from ISP1. > Likewise, mark 2 for all packets from 10.215.144.7 will send through ISP2, and so on... > > That works fine for clients within host2''s subnets that reach the internet via host2+host1 unless there''s a proxy in between. > > Suppose clients within a host2 subnet are required to use an HTTP proxy such as Squid to browse the web, then host1 will mark all of the packets the same way since they will be originating from the same IP address, the one where the HTTP proxy is at. > So host1 won''t be able to mark differently according to the source IP address unless the proxy in host2 (or within a host2 subnet) somehow "spoofs" it''s IP address and impersonates the client''s address. > > Can an HTTP proxy do that? > I also require proxy user authentication via a winbind auth plugin so I can''t use a "transparent proxy" or tproxy, I guess. > > Would marking packets on host2 (the inner shorewall router) the same way host1 would mark them, be a workaround, provided the Squid proxy is on the same server as shorewall (ie. host2)? > That way, I guess that packets would be marked before being handled by Squid on host2 and sent to the Internet via host1. > > Any ideas?It is my understanding that the latest versions of Squid preserve packet marks; I haven''t tested it. If that is the case, then doing all proxy on host1 would be a solution. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ uberSVN''s rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
On 10/08/2011 19:30, Tom Eastep wrote:> It is my understanding that the latest versions of Squid preserve packet marks; I haven''t tested it. If that is the case, then doing all proxy on host1 would be a solution.It''s a feature of Squid 3.2, which is nominally somewhere between alpha and beta quality right now. The patch is fairly sane though and someone who cared could probably easily retrofit it to squid 3.1? Note it''s a compile time option Basically it copies (I think?) the connection mark from the input side, to the output packet mark on the output side (please check connection/packet mark assumptions...). Remember neither of these marks exists outside of the box they are set on... If you want to do this on something other than host1, then you will need to think of some way to mark the tcp packet to show host1 how to route it... Alternatively find some other way to auth (captive portal type auth?) and use tproxy? Just an FYI, but dnsmasq latest version has/will acquire the same packet mark copying in the next version (probably due out any day now). Once you start thinking about this, you realise you can do some interesting things to track stuff through "proxies" Good luck Ed W ------------------------------------------------------------------------------ uberSVN''s rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev