HTTPS traffic being dropped from a single host by FORWARD chain

[this is now an FYI, as whilst writing this, I found the issue - others may benefit from this, so i'll complete the post]

I have a single PC on my network, and some https traffic (all to either google, facebook or instagram) is being dropped against rule 60002.

<30>May  5 21:03:50 192.168.2.100 2021:05:05-21:03:50 home ulogd[4795]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth2" outitf="eth1" srcmac="3c:7c:3f:1d:a2:b2" dstmac="00:30:18:cd:76:19" srcip="192.168.1.102" dstip="142.250.187.202" proto="17" length="1248" tos="0x00" prec="0x00" ttl="127" srcport="62226" dstport="443"

I do block traffic to certain countries, but the targeted servers are all US-based (and they'd result in a 60019 if they were GEOIP blocked)

I do not [knowingly!!] block any web traffic, but I do use a pihole. As we've even got as far as the FORWARD chain, it's not the pihole causing it.

I have all my logs in splunk, and there are exactly two hosts impacted, one I expected to be there, this one I did not.

The PCs user just reports that it's a little slow sometimes, but it works.

The 'default' Web Surfing rule is still there, the local networks are all in the source list, https is in the service list and the destination is still Any. Logging is now enabled, but as the user is at school, there'll be no traffic for a few hours. 

I only have Network Visibility, Remote Access, Firewall, and WAF enabled, so no web filtering.

This is the applicable chain and hash set:

home:/root # iptables -S |grep "logmark 45"
-A USR_FORWARD -p tcp -m set --match-set nXzXM4O6tKcisM4XsXdosA src -m tcp --sport 1:65535 -m multiport --dports 8080,443,80,3128 -m logmark --logmark 45  -j LOGACCEPT
home:/root # ipset -L  nXzXM4O6tKcisM4XsXdosA
Name: nXzXM4O6tKcisM4XsXdosA
Type: hash:net
Revision: 2
Header: family inet hashsize 4 maxelem 65536
Size in memory: 536
References: 1
Members:
172.16.100.0/24
192.168.1.0/24
192.168.2.0/24
192.168.0.0/24

Internet is on eth1, client in question is on eth2. it's not a new thing, it has been happening since the day the PC arrived but on a very low level. There have been one or two days with 8k hits, 10 days with ~500 but the bulk of the time there are no hits (none in March at all). Since 27th April, we've been into the thousands every day.

As I mentioned in my original comment at the very top, I have found the root cause. I have turned on logging, and I can now see accepted and dropped packets next to each other. The ones being dropped are UDP, and they don't hit the rule because the default 'Web Surfing' service group only has TCP configurations for HTTP and HTTPS.  Add two new UDP-based services to the 'web surfing' group, problem solved.

QUIC Protocol (link to Wikipedia) is exactly this scenario, a protocol implemented HTTP with TLS  over UDP. The user's browser choice is Firefox, and Mozilla enabled QUIC by default on new builds after 16th April. First update he did was on April 27th, which is when the logs started.

There is a bulletin here about QUIC bypassing scanning on XG, with instructions on how to block the traffic. It appears that QUIC is in the list of applications you can control under Network Visibility, but you can also block it with a drop rule for UDP ports 80 and 443.

HTH

Dave