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
- gkarasikGuideThanks very much for taking the time to post this.
GaryK - MPNAspirantThis solved our problem as well. Our FVS318N kept having DNS problems, but when I switched to our FVS336G, no problems. Tried different firmware versions and a different FVS318N, nothing helped.
Turns out, the FVS318N has "Block UPD flood" on be default and the FVS336G has it off by default. No problems now. - silvexAspirantThe wireless VPN FW SRXN3205 has the same issue and I did the same "fix".
- andyandersonAspirantThank you Ssawyer for this information. I applied it to my three SRXN3205. I was about to remove all three of them from service because of this. I have contacted Netgear Support (if we really want to call them that) multiple times about this issue. Thank you again!
- giusiofAspirantHi,
unfortunately this solved only some problems.
I updated to Firmware 4.2.1-2 and I'm experiencing intermittent connections yet.
I disabled any type of log on security and udp flood on attack checks , so this is the result
Thu Jan 3 18:14:31 2013(TZi-) [SRX5308][Kernel][KERNEL] cvm_ipfwd_cache_flow: Failed to allocate flow info buffer
<4
Thu Jan 3 18:11:26 2013(TZi-) [SRX5308][Kernel][KERNEL] cvm_ipfwd_cache_flow: Failed to allocate flow info buffer
<4
Thu Jan 3 18:11:26 2013(TZi-) [SRX5308][Kernel][KERNEL] cvm_ipfwd_cache_flow: Failed to allocate flow info buffer
Thu Jan 3 18:11:26 2013(TZi-) [SRX5308][Kernel][KERNEL] cvm_ipfwd_cache_flow: Failed to allocate flow info buffer
Thu Jan 3 18:11:26 2013(TZi-) [SRX5308][Kernel][KERNEL] cvm_ipfwd_cache_flow: Failed to allocate flow info buffer
Thu Jan 3 18:11:21 2013(TZi-) [SRX5308][Kernel][KERNEL] cvm_ipfwd_cache_flow: Failed to allocate flow info buffer
<4
Anyone has this problem?
Thanks - volkuhlAspirantsame problem for me...
- SDMNovicesame problem for me...
El mismo promema para nosotros...
SRX5308 - jzelosAspirantNB: I've got a ticket open with netgear referencing the below thread for the "cvm_ipfwd_cache_flow" issue.
http://forum1.netgear.com/showthread.php?t=81403 - JellyBeanGreenAspirantYour the best, I spent hours upon hours trying to find an answer... I read your post, click, done!
Thanks :) - GDHuberAspirantThank you so for this post, problem resolved.
I hope Netgear reads this and up-dates the firmware.
Related Content
NETGEAR Academy

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