Since UDP is a connectionless protocol, I'm confused by the setting on my Sonicwall Firewall for "UDP Connection Timeout". It's set at a default of 30 seconds -- but what exactly times out after 30 seconds?


Here's my actual real-world situation: I have an NTP server in the ntp.org pool that serves about 3000 queries per minute. This puts a bit of a strain on my SOHO grade TZ-200 -- not in terms of bandwidth; but in terms of # of connections it has passing through it. I'm wondering if the UDP connections somehow are 'kept alive' on the SonicWall; even though they're (by definition) connectionless.

What am I missing here? What does SonicWall mean when it talks about a "UDP Connection Timeout"?

  • Firewalls usually allow packets for a connection that was established by a machine inside the firewall. But UDP has no connections. So the choices are to allow all UDP packets, block all UDP packets, or try to guess what the "UDP connections" are so only allow packets that are part of those "connections". All(?) firewall vendors take the last approach. Commented Dec 30, 2016 at 10:34
  • As immibis has described. Due to Network Address Translation or NAT an internet/subnetwork gateway router will only allow TCP (virtually all traffic is TCP) in which a client on subnetwork initiates the connection. For there is no way to assign a port for the NAT if the connection is incoming. How does the router know who to send it to? UDP doesn't even have a connection so how is the router to handle UDP requests commming in? One way is to keep track of outbound UDP packets. Commented Jan 4, 2017 at 16:26
  • If you are hosting a server you should forward ports you expect to receive connections on, though be prepared for anything. Commented Jan 4, 2017 at 16:28

4 Answers 4


While there is no formal "connection" with UDP there is still a convention that clients send requests and expect to get responses back with the source IP and port swapped with the Destinatoin IP and port.

Stateful firewalls and NATs therefore assume that packets with a given combination of source IP/source port/Destination IP/Destination port and the corresponding combination with source and destination swapped form part of a "connection". This allows rules like "outgoing connections only" to be applied to UDP and allows reverse translations to be applied to response packets.

Unfortunately the firewall or NAT has no way of knowing when the client has finished talking to the server. So it has to wait for a timeout before removing the entry from it's state tracking tables. That is the timeout you are setting.

In principle it would be possible to build a NAT box that used a stateless approach for port forwards while maintaining a stateful approach for outgoing connections but it's simpler to just use stateful NAT for everything and it sounds like this is what your vendor is doing.

Unfortunately as you have discovered this sucks for stateless UDP servers serving large numbers of small requests. You end up in a situation where the firewall consumes far more resources than the sever itself.

  • 2
    Thanks for the great answer Peter! In my case, SonicWall allows me to reduce the UDP "connection timeout" on a particular firewall rule, so I'll reduce the NTP policy's rule to 5 seconds (from the default of 30). Commented Dec 30, 2016 at 18:01
  • 2
    Note: After doing that, I saw the 'total connections' as reported by the Sonicwall drop from ~1500 to ~400. Perfect! Thanks again for the great answer. Commented Dec 30, 2016 at 18:02
  • 3
    Be aware that most streaming protocols use UDP, that includes the media portion of VOIP (after it is negotiated using SIP). Having that short of a timeout can cause a problem if there is no traffic (e.g. call put on hold, both sides muted, etc) as not all VOIP phones (hard or soft) are great at renegotiating the media connection if the ports get dropped. Others use a 'keep alive' by sending tiny signals on a periodic basis, which could well be further apart than 5 seconds. Commented May 6, 2017 at 0:23

Your firewall is maintaining a connection table for UDP connections. For example, when you send a DNS query, the firewall creates an entry for that flow so that the DNS reply will be allowed back into your network. The entries in the table time out after 30 seconds of no activity.

  • Thanks Ron. Can you comment on that Connection Table, with regards to Inbound connections? Since my NTP server is on the inside, there shouldn't really be a need to 'keep the door open' for those inbound connections, since my Server on the inside can always get back out to the source (I have wide-open outbound rules). Thanks for the quick answer! Commented Dec 29, 2016 at 23:45
  • 3
    The connection table is built regardless of the direction of the connection and is actually immediately used for the response packet coming back from your server through the firewall returning to the querier. The firewall is maintaining a tuple of (src ip, src port, dst ip, dst port) to associate the initial query with the response. Since there isn't really a semaphore to indicate to the firewall that a particular UDP session is finished and the socket has closed the timeout value ends up being used.
    – rnxrx
    Commented Dec 30, 2016 at 3:34

Your NTP server is behind your NAT (firewall). UDP is connectionless from the point of view of the application and OS and for most network appliances along the way.

For your NAT firewall, however, it records whenever a UDP packet goes out so that a response from the other end will end up being redirected to the same computer inside your network. These get called "connections" by the firewall.

Now, in theory, the NAT knows that the external port will be the NTP well known port, but it looks like your firewall doesn't support that. If this is your only use for UDP through this firewall, you could set the Connection timeout to a smaller number. Alternately, if it lets you set by application port, you could set it to a smaller time (1 second, say) for that specific port.

  • 1
    The timeout isn't specific to NAT; any stateful firewall will have one. Commented Dec 30, 2016 at 7:26
  • The firewall doesn't do NAT instead it is trying to filter packets which are transitioning through NAT, thus the inter-relation to the router and NAT. Commented Jan 4, 2017 at 16:31
  • A gateway router to the internet Must employ NAT because any computer sits on a subnet, only the gateway router has an actual internet IP address. It would be immensely wasteful if every single computer was a thing on the internet. The gateway router has sometimes a large group of computers which all are associated with one internet IP address. It uses a berkly web socket to be able to translate a one to one between incoming packets from the web and computers on its network. People seem to not get this. Commented Jan 4, 2017 at 16:37

IPv6 doesn't need NAT, yet it still appears as though firewalls are stateful with respect to UDP.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.