NAT Traversal 是您所描述的标准解决方案。具体来说，您需要验证 NAT Traversal keep alive 设置。让我解释。
您很有可能在 ESP 模式下使用 IPsec。在非NAT穿越场景下，你的数据包会是这样的（协商后）：
[Outer IP header][ESP Header][Encrypted/Authenticated Data][ESP Trailer]
外部 IP 标头将包括您的 VPN 网关设备（您的 NSA 2400）的源/目标 IP 以及远程办公室使用的任何 WAN IP。
在您的情况下，您有多个客户端共享一个源 IP——这是一种非常常见的 PAT 配置。因此，远程路由器需要重写每个客户端的源 IP 以及源端口。如果该路由器遇到上述数据包（在 L3 标头和数据之间没有 L4 标头），它会丢弃它，声称它是格式错误的数据包。
NAT Traversal 在数据包中插入一个额外的 L4 标头。所以它看起来像这样：
[Outer IP header][NAT-T UDP 4500 header][ESP Header][Encrypted/Authenticated Data][ESP Trailer]
此标头以 UDP 源和目标端口 4500 开头（默认情况下，这是可配置的）。目标端口通常不会更改（在通往您的 VPN 前端设备的路由上）。源端口通常不会得到由瞬态NAT设备（在这种情况下，远程办公室路由器）改变。
现在。大多数状态防火墙或路由器具有非常低的 UDP 连接超时。UDP 本质上是无连接的，因此 UDP 连接超时不到一分钟是很常见的。如果我记得的话，Cisco ASA 是 30 秒（不要引用我的话，这是凭记忆）。相比之下，TCP 超时本身就很高，因为通常有状态设备正在寻找 RST 或 FIN 以从其连接表中清除条目。TCP 超时只是一个停止间隙，以防通信的两端同时爆炸并且无法发送 RST/FIN。所以 TCP 超时高于 UDP 超时是正常的，甚至是建议的行为。
话虽如此，我们可以描述您的问题可能发生了什么......
如果远程办公室客户端第一次连接，并且它们的 NAT-T 标头的源端口被重新写入 2222，则 VPN 前端设备将期望该特定 VPN 连接的所有未来通信都以 2222 的源端口到达. 它还将封装所有返回流量并将其发送回远程路由器的 IP，目标端口为 2222。只要此特定 NAT 转换在远程路由器中保持活动状态，这将正常工作。
但是如果远程路由器清除了它的 NAT 转换表，从客户端发送到服务器的下一个数据包将获得一个新的 UDP 源，比如 3333。当它到达 VPN 头端设备时，它会认为它是一个新的“连接”，并且期待对 IPsec 进行全面的重新协商（从安全的角度来看，这是正确的做法）。
此外，如果远程路由器清除了它的 NAT 转换表，并且下一个发送的数据包是从服务器到客户端（也就是，目的地是端口 2222），远程路由器将没有该源端口的任何出站转换记录，因此数据包将被简单地丢弃。请记住，PAT 是单向的。
说了这么多。由于 VPN 连接进入静音状态是常见且完全正常的。NAT Traversal 中内置了一个称为“NAT Traversal Keepalive”的功能。它只是一个空数据包，每 10-15 秒（因实现而异）从客户端发送到服务器，并且此数据包的唯一目的是使 NAT 转换在瞬态 NAT 设备（如远程路由器）中保持活动状态。
所以在我看来，你的 NAT Traversal Keepalive 设置得太高了。我将从减少那个开始。因为这是您可以在头端设备上进行的软件更改，并且应该会影响您的所有客户端，而不会强迫您更换另一端的硬件。
最后，重申 Ricky 提到的内容。如果任何超时需要调整，它将在远程路由器上，而不是在 VPN 头端设备上。