<div dir="ltr">FYI, I finally solved my problem!<div><br></div><div>It turns out the problem was with PRE-ESTABLISHED connections...</div><div><br></div><div>In other words, when I turned on my transparent rules, any Chrome tabs I had opened BEFORE turning on my transparent proxy rules, apparently would communicate over a previously opened socket! So the filtering rules would only apply after the port was closed OR after I reopened the browser.</div><div><br></div><div>In order to solve it, I simply had to add a FORWARD drop rule for any established connections:</div><div><div>iptables -A FORWARD -p tcp -m tcp --dport 80 -m state --state RELATED,ESTABLISHED -j DROP</div><div>iptables -A FORWARD -p tcp -m tcp --dport 443 -m state --state RELATED,ESTABLISHED -j DROP</div></div><div><br></div><div>Hope this will be helpful to someone else!</div><div>Luis</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 7, 2015 at 8:28 PM, Luis Miguel Silva <span dir="ltr"><<a href="mailto:luismiguelferreirasilva@gmail.com" target="_blank">luismiguelferreirasilva@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ok, I'm using 3.4.9, so I've added that config option to my setup :o)<div><br></div><div>Thanks for the tip!</div><div>Luis</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 7, 2015 at 6:11 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/02/2015 5:34 a.m., Luis Miguel Silva wrote:<br>
> I did when you sent it but it seemed to me you were saying I should add<br>
> that "reply_header_access Alternate-Protocol deny all" config parameter<br>
> but, on the other hand, I didn't understand why were you suggesting that,<br>
> seeing that my problem is that Chrome doesn't go through my proxy at all!<br>
> (I'm doing transparent proxying, NOT setting up a proxy in Chrome).<br>
><br>
> I've now re-read your email and it seemed you were telling me to upgrade to<br>
> 3.5.x (which I hadn't understood the last time I read your email). I<br>
> apologize that I didn't understand what you were saying.<br>
><br>
<br>
No wrries. I was saying both.<br>
<br>
> So are you saying I must upgrade to Squid 3.5.x to fix this? Why would that<br>
> header fix it, seeing that my problem is that Chrome is bypassing the proxy<br>
> altogether?<br>
<br>
The web server actively tells Chrome to use QUIC on future requests.<br>
Remove that header from traffic and Chrome stops using QUIC (maybe<br>
requires Chrome restart).<br>
<br>
The removal is built into 3.4.10+ by default, but the config line I<br>
presented does the same thing in older versions back to 3.2.<br>
<span><font color="#888888"><br>
Amos<br>
<br>
</font></span></blockquote></div><br></div>
</blockquote></div><br></div>