Sonicwall fix for QUIC UDP Issue

If you want the super quick answer it’s “UDP Flood Protection”, increase packet limit or disable it.

Now the journey and longer answer:

Fixing my own problems are always the hardest, I guess it’s because they’re memorable, little irritations that I fix for customers I do for myself instantly without even thinking about it or I don’t let me systems get to the point that some customer systems end up at.

This one was nagging me for a long time but I never took the time to dig into it. Whenever I was at a customer site and took photos, I’d return to the office and need to download the photos from google photos, google photos bundles a custom zip for me to download. It almost always failed, it would go for a bit, then slow down and then just stop with “Network Error”

I noticed a similar situation with OneDrive as well. If I started a VPN, it was not an issue, so that was my workaround because I was too busy fixing other peoples computers.

I had some downtime after our company Christmas lunch so while multitasking on two other projects, I finally got something resolved (of course, it was the least critical one)

I was doing Sonicwall packet captures on another project when I ran into the issue again, I mentioned it to a coworker and no one else in the office had noticed, go figure. I decided why don’t I capture this traffic on our Sonicwall and my PC and see what the difference was, I already had an inkling that maybe the Sonicwall was the root of the problem.

I examined the capture and quickly noticed this was using QUIC, I know a little about QUIC but haven’t encountered it as a key element in a packet capture.

It’s encrypted so the captures didn’t tell me much. So I started some GoogleFu and landed on this page:

https://randomlylearned.blogspot.com/2017/01/google-not-working-with-sonicwall-only.html

I tried disabling QUIC in Chrome, transfers worked and worked fast, however I wasn’t satisfied with turning it off because my understanding is this is the future HTTP/3 protocol. We’re just putting the problem off to the future and I can’t stand that.

I turned it back on and of course transfers fail. I started more searches, the best techs know good search queries, so I ran this:
udp settings for “quic” sonicwall reddit

Reddit has a lot of good information so I like to sometimes just loop it in so it’s a top result. The second link was this page:

PSA: If you use Sophos UTM (and possibly Sophos XG), do not enable UDP flood protection as it will kill Google sites from networking

This matches the issue description perfectly and made the same connections I’d already made just with a different firewall.

So I found a matching setting in Sonicwall Firmware 7:

This is a customer’s setup, so it seems UDP Flooding is not enabled by default, but if it’s enabled it’s rather strict at 1000 packets/sec

If I recall correctly ours was set to 10,000 or something like that, likely set for our phone RTP and SIP traffic.

I boosted this to 50,000 and everything works, but I’d like to make this as close to a reasonable number as I can.

It kind of bugs me that Sonicwall gives us a lot of information except possibly the most important one of all, what the max udp packet/sec speed was over some period of time.

Now that I look at that, I’m wondering if we were at 100 for a time because that might explain why the average is 99, anything over that gets dropped.

I ran another local packet capture while transferring a zip with many pictures in it. Then examined Statistics->I/O Graph

So that was one PC downloading from google, we can round that to 20k and let’s say we have maybe three people doing the same sort of download at the same time, could hit 60k. If HTTP/3 takes off we may need to revisit this entirely or disable it entirely.

I considered a better estimate would be to monitor the system over a long period but I wanted to also make sure there wasn’t background UDP overhead that we may need to account for.

I configured a Sonicwall packet capture focusing on these parameters:

I’m guessing the UDP packet per second is measured only once, so that’s why I added X1 so we did pick up ingress and egress packets as the sonicwall will do by default.

So background after about a minute is minimal

So I’m going to set it to 80k, I think that’s a reasonable number, now to find a UDP flooding or reflection attack to test it after hours. I’ll leave that exercise up to the viewer or else maybe a future post, that’s super low priority at the moment.