QUIC Visibility

[darthrater]

I was testing a SASE deployment and UDP 443 refused to connect. I had webfilter, app control, firewall, and threat detection enabled on the policy. I went through every report looking through a block indication, and traffic wise everything seemed fine.

It wasn't after I went through each application setting that I found the (on by default!) quic block option. This is frustrating because I just have web filtering on to grab information about sites visited, and no categories blocked. The app was not enabled with the intention to block anything.

It wouldn't be so bad if the website reports reflected the block, but the 443 traffic was all unblocked. Also, the webfilter report does not let me add the protocol field so I could not drill down as far as I wanted to go.

Please, if you are going to have a default block somewhere, have it show up in the logs.

[sky-knight]

The problem is QUIC is not HTTPS. And QUIC being allowed basically means Web Filter is disabled, because it'll never see what's going on via that protocol, and worse there's no means to make it see it.

I don't mean this to say Web Filter just doesn't have the feature to do this. I mean that it's literally impossible to inspect the traffic to get the detail you need from a QUIC session.

Which is why it's blocked by default. Since QUIC isn't a standard, blocking it generally imparts no harm, the impacted service will fall back to HTTPS which provides a fair bit of unencrypted data to the filter that logs what you can see in the reports.

[darthrater]

Sure, though Fortigate (I left Forti for Arista NGFW and not going back) could see quic and it showed up as blocked in their logs when I blocked it. For SASE applications, these do not fall back to HTTPS, which caused the issue until I found the setting and unblocked it.

I still respectfully maintain that if a firewall is going to block something (especially when blocking by default) , it should be in the logs.