What traffic does the web proxy intercept?

In Standard Mode, a compliant web browser says "proxy, please fetch this for me".   This allows Standard Mode to process traffic on any port number.    (It also allows for better user attribution for https traffic.)  The UTM configuration blocks all non-standard ports by default, so you need to monitor the logs to decide what additional ports you want to permit.   (Filtering Options... Misc... Allowed Target Services)

I say "compliant" browser, because nothing guarantees that any software on the client will actually use the configured Standard Mode proxy.   So you want to leave Transparent Mode enabled as well.

Transparent Mode does not recognize that a packet is in HTTP/HTTPS format, it simply assumes that if the traffic is on ports 80 or 443, then it must be http(s) and it activates its logic.   I don't think the Transparent Mode does anything with the additional ports list.

As discussed elsewhere, Chrome's browser, with the QUIC protocol enabled, tries the following sequence:   

• UDP 443 with Standard Proxy, which is blocked by default at UTM
• UDP 443 without proxy, which will hit the Firewall Rules and bypasses all web proxy functions
• TCP 443 with Standard Proxy
• TCP 443 without proxy, which will hit the Transparent Proxy.

To ensure that Chrome traffic goes through your proxy, you need to add UDP 443 to the additional ports list or block UDP 443 at the firewall. 

More generally, my goal is to identify all legitimate sources of UDP traffic, configure firewall Allow rules for them, and block everything else on UDP.   UDP is ideal for malware that wants to hide in plain site.  I got started on this analysis, then got distracted onto other things.

In Standard Mode, a compliant web browser says "proxy, please fetch this for me".   This allows Standard Mode to process traffic on any port number.    (It also allows for better user attribution for https traffic.)  The UTM configuration blocks all non-standard ports by default, so you need to monitor the logs to decide what additional ports you want to permit.   (Filtering Options... Misc... Allowed Target Services)

I say "compliant" browser, because nothing guarantees that any software on the client will actually use the configured Standard Mode proxy.   So you want to leave Transparent Mode enabled as well.

Transparent Mode does not recognize that a packet is in HTTP/HTTPS format, it simply assumes that if the traffic is on ports 80 or 443, then it must be http(s) and it activates its logic.   I don't think the Transparent Mode does anything with the additional ports list.

As discussed elsewhere, Chrome's browser, with the QUIC protocol enabled, tries the following sequence:   

• UDP 443 with Standard Proxy, which is blocked by default at UTM
• UDP 443 without proxy, which will hit the Firewall Rules and bypasses all web proxy functions
• TCP 443 with Standard Proxy
• TCP 443 without proxy, which will hit the Transparent Proxy.

To ensure that Chrome traffic goes through your proxy, you need to add UDP 443 to the additional ports list or block UDP 443 at the firewall. 

More generally, my goal is to identify all legitimate sources of UDP traffic, configure firewall Allow rules for them, and block everything else on UDP.   UDP is ideal for malware that wants to hide in plain site.  I got started on this analysis, then got distracted onto other things.

Cheers Douglas,

so security wise, I'm leaning towards Standard mode as I have full control of my subnets and the devices which reside on them. I currently had Transparent mode and no FW rules for 80/443.

I get the odd timeouts etc with https etc but other than that, it worked fine. Now I was getting a FW port block on a TCP 9280 which I didn't pay much attention to as I assumed it was just a port from 200+ clients trying to get out. I should have paid more attention.

Switching over to standard mode, straight away it showed http://xxx.interesteddomain.com:9280/xxx/xxxx which alerted me certain clients being blocked for a service that should be allowed. Standard mode give me a bit more of an insight rather than just the FW with IP's. Transparent mode just didn't pick this up at all.

So I'm leaning towards standard mode with auth for the subnets/clients I have total over and using transparent no auth for those that I don't.

One question though...... am i heading in the right direction? Should I aim to employ standard mode or aim towards using transparent totally?

I am an enthusiastic supporter of deploying both modes to internal users:   Standard Mode for your web browsers, and Transparent Mode for everything that ignores Standard Mode.   Have been using Standard Mode for years, Transparent Mode added more recently.    I have written about this in my post about "web filtering lessons learned", and in some early documents which are in the WiKi.

You will hit an occasional site that doesn't work, but this is not much different than debugging webfilter generally.

DNS is performed at the UTM instead of at the client.   If you have a DMZ that uses external DNS, changing the DMZ to Standard Mode can change the DNS results seen by the machines in the DMZ.   I recommend using only transparent mode for DMZ-based devices, guest network devices, and VPN clients.