NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ssawyer
Oct 13, 2012Follower
Easy Fix for Intermittent Connections, Slowdowns, Timeouts - DNS related, SRX5308
I'm documenting this here, because I didn't see anything about it in my forum searches, and I believe that it's likely to be a common problem with an easy fix.
I had just installed a new Netgear SRX5308 VPN/Firewall in our network (5 VLANs, about 70 users and around 200 devices total). Everything seemed to be working fine, but — randomly and intermittently — new connections would be slow or time out. So users would experience web pages loading slowly, or failing to load at all, but then working again on a second try, etc.
Netgear support couldn't help much with it, so I did more of my own diagnosis, and eventually found that it was related to DNS lookups slowing down or failing intermittently when going through the firewall; if I was outside the firewall, everything was fine.
I then found the solution myself: to uncheck the "Block UDP flood" on the "Attack Checks" configuration of the firewall settings. Since I deactivated it, everything has been working fine.
I then went back and looked in Netgear's documentation — apparently, the "Block UDP flood" option, which is enabled by default, triggers when it has 20 or more simultaneous UDP connections from a single LAN-side client. And of course, DNS works over UDP port 53, so we were seeing intermittency whenever we got to >20 DNS requests at the same time from a client. (And, in fact, the current manual acknowledges this in a note on p. 136 — which is in the firewall rules section and unfortunately not referenced in the Attack Checks section).
The reason I think this is likely a common problem: 20 simultaneous connections is WAY TOO LOW for modern browsers and network usage; an single average webpage can load material from its own server, 2-4 social networks, various sources for Javascript libraries, fonts, CSS, etc., and CDN servers for images — all of which require DNS lookups. You could easily get to 20 on a single page, even without accounting for stuff the computer is doing in the background that might involve DNS lookups or other uses of UDP.
There are, I think, a few options for how Netgear should fix this:
(a) set a separate policy for dealing with a flood of DNS UDP traffic on port 53 with a better (or configurable!) connections limit
(b) make the number of simultaneous UDP connections configurable overall
(c) MINIMALLY, make sure that when "Block UDP flood" is triggered, there's a clear log message about set up under default logging conditions — the place this got really painful was that I couldn't determine from the firewall's logs why the firewall had dropped my traffic; had I seen something about "Block UDP flood" in the logs, I would have been able to fix it myself without having to call.
But anyway: at least on the SRX5308, there's a simple setting, on by default, that causes DNS requests to be dropped under conditions that are fairly normal in modern networks. If you're having connection timeouts — especially if you can track them to failed or slow DNS lookups — try turning of "Block UDP flood" in the "Attack Checks" section of firewall policy.
I had just installed a new Netgear SRX5308 VPN/Firewall in our network (5 VLANs, about 70 users and around 200 devices total). Everything seemed to be working fine, but — randomly and intermittently — new connections would be slow or time out. So users would experience web pages loading slowly, or failing to load at all, but then working again on a second try, etc.
Netgear support couldn't help much with it, so I did more of my own diagnosis, and eventually found that it was related to DNS lookups slowing down or failing intermittently when going through the firewall; if I was outside the firewall, everything was fine.
I then found the solution myself: to uncheck the "Block UDP flood" on the "Attack Checks" configuration of the firewall settings. Since I deactivated it, everything has been working fine.
I then went back and looked in Netgear's documentation — apparently, the "Block UDP flood" option, which is enabled by default, triggers when it has 20 or more simultaneous UDP connections from a single LAN-side client. And of course, DNS works over UDP port 53, so we were seeing intermittency whenever we got to >20 DNS requests at the same time from a client. (And, in fact, the current manual acknowledges this in a note on p. 136 — which is in the firewall rules section and unfortunately not referenced in the Attack Checks section).
The reason I think this is likely a common problem: 20 simultaneous connections is WAY TOO LOW for modern browsers and network usage; an single average webpage can load material from its own server, 2-4 social networks, various sources for Javascript libraries, fonts, CSS, etc., and CDN servers for images — all of which require DNS lookups. You could easily get to 20 on a single page, even without accounting for stuff the computer is doing in the background that might involve DNS lookups or other uses of UDP.
There are, I think, a few options for how Netgear should fix this:
(a) set a separate policy for dealing with a flood of DNS UDP traffic on port 53 with a better (or configurable!) connections limit
(b) make the number of simultaneous UDP connections configurable overall
(c) MINIMALLY, make sure that when "Block UDP flood" is triggered, there's a clear log message about set up under default logging conditions — the place this got really painful was that I couldn't determine from the firewall's logs why the firewall had dropped my traffic; had I seen something about "Block UDP flood" in the logs, I would have been able to fix it myself without having to call.
But anyway: at least on the SRX5308, there's a simple setting, on by default, that causes DNS requests to be dropped under conditions that are fairly normal in modern networks. If you're having connection timeouts — especially if you can track them to failed or slow DNS lookups — try turning of "Block UDP flood" in the "Attack Checks" section of firewall policy.
21 Replies
- sdahlstromAspirant
Remembering this thread. thank you so much, I've been looking for this solution...
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!