Google QUIC protocol issues
-
So I have seen here and there mentions of the QUIC protocol and people trying to block it. Since everyone in my family is on Google and uses a Android phone and Chrome Browser on their laptops, I was getting complaints about slow Youtube, quic error message in Google Chrome, etc. I saw where QUIC uses port 80 and 443 both over UDP and even though I had a rule allowing it from any LAN source, it still had issues. The only workaround I have found so far is to block traffic over 80/443 UDP plus disable QUIC protocol in Chrome via the chrome flags.
The above Chrome flag fix worked on the laptops, but the issue still remain for things like the YouTube app on Android Phones. Anyone had similar issues? Solutions? I would love to fix this at the firewall level and not have to fix a bunch of client devices.
-
Hi,
I had to look up what that actually is, QUIC..
Is is comparable to SPDY, and if so, then https://blog.chromium.org/2015/02/hello-http2-goodbye-spdy.html
http/2 is the future for every browser.pfSense handles TCP and UDP just fine, on every port. If something is blocking it for you, then it must be something upstream. Tread the mentioned Wiki page - and point number https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf : it appears "some users" have UDP connectivity problems.
Possible, but be assured that doesn't come from pfSense. -
QUIC is a layer 4/5 protocol that works around poor TCP implementations by streaming over UDP and handling congestion control itself. I assume BBR or something similar will replace this once TCP congestion control algorithms stabilize. A few main goals. Reduce buffer bloat, don't be so sensitive to loss because wifi is lossy, be sensitive to congestion based loss, quickly maximize bandwidth, packet pacing.
HTTP2/SPDY are layer 7 protocols. One of the main benefits is asynchronous multiplexing over a single stream, which allows browsers to stop creating tons of connections due to head-of-queue blocking in HTTP1.1. Lots of TCP connections are bad. Not only eat up more resources, but the have a "thundering herd" problem due to natural synchronization that occurs, and effectively a scaling factor on top of "slow start", making slow start less slow resulting in larger bursts that over congest links.
-
Hi,
so what is the solution? When will pfsense be able to filter such connections (quic)?
I hope soon.
-
Define "filter". pfSense itself does not care
aboutabove Layer 4. Some of the custom packages might. -
"to block traffic over 80/443 UDP"
Looks like your already filtering it at firewall to me..
You might want to change that to a reject, so your clients will know right away that its blocked and not have to wait for timeout, etc.
