We have a SonicWALL NSA 2400. We have numerous (100+) personnel in different offices in different physical locations that establish VPN sessions successfully every day. Some of these client computers are behind routers. One of these offices is reporting that, with four office computers, they sometimes cannot get some or all of their four VPN sessions to connect.

When I check our SonicWALL logs, I see that our NSA 2400 is receiving packets from their office router. Our NSA then tries to acknowledge these packets, but this results in a time-out message for the ack. (Unfortunately, I don't have the specific error messages.)

I checked our settings and our UDP timeout value for this connection (LAN->VPN) is 30 seconds. This seems low and I would like to increase this in an attempt to remedy the problem with the timeout ack messages, but I don't know what effect this will have on the rest of the connecting VPN sessions. Our TCP timeout value is 900 minutes, by the way, for reference. I suspect some previous administrator changed the TCP settings but forgot/ignored the UDP settings.

The NSA logs also have messages about UDP packets being dropped, as well, both incoming and outgoing. The messages are for various port numbers and services (DNS, IKE (Transversal), etc.), so changing the UDP settings might help in removing these messages.

My fear is that changing these settings will affect the existing VPN connections. However, the NSA has 512 MB of RAM and our peak connection usage has been around 6200 connections out of 32000 max. We run about 1500 connections on average.

I have researched this on the web, but have only found general troubleshooting recommendations to "increase the UDP timeout and see if that fixes it".

So will increasing the UDP timeout to 300 seconds negatively affect the other existing VPN connections? It doesn't look like we are close to our connection limit.

  • Is the NSA dropping all UDP packets, or just from that office? Are your VPN packets encapsulated in UDP or TCP? I suspect there is a problem with that office, especially if they are the only ones reporting the problem.
    – Ron Trunk
    Oct 8, 2015 at 19:24
  • The NSA does seem to be dropping UDP packets, but I don't know if any are getting through or not. During normal operation for the other clients, I see that the following UDP packets commonly get dropped: UDP IKE (Transversal) Port 1900 Port 33434 This has happened with other offices in the past. These other offices ended up replacing their routers and the problem stopped. However, this office owner is wanting to know exactly why he should replace the router, thus I am ensuring that our NSA is setup in the best way possible for all connections.
    – Disco
    Oct 8, 2015 at 19:30
  • I don't know how our VPN packets are encapsulated. Our settings include both TCP timeouts and UDP timeouts, but that is all I can find so far.
    – Disco
    Oct 8, 2015 at 19:35
  • Do you see anything in the NSA log file? The timeout value defines a UDP "data flow." 30 seconds sounds normal to me.
    – Ron Trunk
    Oct 8, 2015 at 19:35
  • Sorry, the UDP packets that are dropped are what I found in the NSA log file during normal ops with other VPN sessions. I do not have the NSA logs for the problem office in question, I only have the notes from the previous admin, which describe the problem as "time out messages occurring when our VPN server attempts to connect back to their office router IP".
    – Disco
    Oct 8, 2015 at 19:37

2 Answers 2


NAT Traversal is the standard solution for what you are describing. Specifically, you need to verify the NAT Traversal keep alive setting. Let me explain.

More than likely, you are using IPsec in ESP mode. In a non-NAT traversal scenario, your data packets will look like this (after negotiation):

[Outer IP header][ESP Header][Encrypted/Authenticated Data][ESP Trailer]

The outer IP header will include the the Source/Destination IP of your VPN gateway device (your NSA 2400) and whatever WAN IP the remote office is using.

In your case, you have multiple clients sharing a single source IP -- which is a very common PAT configuration. As such, the Remote router needs to re-write the source IP of each of your clients, as well as the source port. If that router were to have encountered a packet like the one above (with no L4 header between the L3 header and the data), it would drop it claiming it is a malformed packet.

NAT Traversal inserts an additional L4 header in the packet. So it would look like this:

[Outer IP header][NAT-T UDP 4500 header][ESP Header][Encrypted/Authenticated Data][ESP Trailer]

This header starts with UDP source and destination port 4500 (by default, this is configurable). The destination port typically does not change (on route TO your VPN head end device). The source port typically does get changed by the transient NAT device (in this case, the remote office router).

Now. MOST Stateful Firewalls or Routers have a very low UDP connection time out. UDP is, by nature, connection-less, so it is very common for UDP connection timeouts to be less than a minute. Cisco ASA's are 30 seconds, if I recall (don't quote me, its from memory). By comparison, TCP timeouts are inherently high, because usually the stateful device is looking for the RST or FINs to purge an entry from its connection table. A TCP timeout is just a stop gap in case both ends of the communication exploded simultaneously and weren't able to send out a RST/FIN. So a higher TCP timeout than UDP timeout is normal, and even suggested behavior.

With that said, we can describe what is probably going on with your issue...

If the first time a remote office client connects, and their NAT-T header's source port gets re-written to 2222, the VPN Head end device is going to expect all future communication for that particular VPN connection to arrive with a source port of 2222. It will also encapsulate and send all return traffic back to the remote router's IP, with a destination port of 2222. This will work just fine, so long as this particular NAT translation stays active in the remote router.

But IF the Remote Router purges its NAT translation table, the next packet sent from Client to Server will get a new UDP source, say 3333. When that gets to the VPN Head end device, it will consider it a new "connection", and expect a full re-negotiation of IPsec (which from a security standpoint, is the right thing to do).

Additionally, if the Remote Router purges its NAT translation table, and the next packet sent is from Server to Client (aka, destined to port 2222), the Remote Router won't have any record of an outbound translation for that source port, so the packet will simply be dropped. Remember, PAT is uni-directional.

All that said. Since its common and perfectly normal for VPN connections to go silent. There is a function built into NAT Traversal called the "NAT Traversal Keepalive". It is simply an empty packet that is sent every 10-15 seconds (differs by implementation) from Client to Server, and the sole purpose of this packet is to keep the NAT translation alive in transient NAT devices, like the remote Router.

So it sounds to me like you have your NAT Traversal Keepalive set to too high. I would start by decreasing that one. Because its a software change you can make on your Head End device, and should affect all your clients, without forcing you to replace hardware on the other end.

Lastly, to re-iterate what Ricky mentioned. If any time out needs to be adjusted, it will be on the Remote router, not on the VPN Head end device.


know exactly why he should replace the router

Because his router is interfering with vpn client operations.

IPSec VPN's use udp/500 for key exchange (ISAKMP, aka IKE) and, typically, udp/4500 for NAT traversal. Once keys and settings are negotiated, the actual tunnel transport is either ESP (IP protocol 50) or AH (IP protocol 51), but AH is not compatible with NAT.

As long as your firewall is not behind some other NAT, changing the firewall's connection timers will do absolutely nothing; those setting are for sessions through the firewall, not connections to/from the firewall. The most likely cause of the problem is the remote office's router.


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.