SonicWALL NSA-2400和NSA-240之间的DHCP每天晚上都会丢失连接。

Question

在我的中心办公室里，我有一个SonicWALL NSA-2400设备作为几个远程办公室的中心。它被配置为将DHCP请求传递给我的内部DHCP服务器。VPN连接工作正常，IP地址按其应有的方式分配到远程办公室，我对结果非常满意--除了一个远程办公室。

上周五，我把NSA-2400号的弟弟安放在一个偏远的办公室里。这两个防火墙在任何时候都报告岩石固体连接，并且通过隧道的网络连接的所有方面都运行良好。我的问题是，到目前为止，每天早上远程办公室都会打电话告诉我，他们没有任何网络接入。在每种情况下，他们都丢失了由我的公司办公室DHCP服务器分发的IP地址，并获得了“垃圾”169.xxx地址。

重新启动防火墙并更新DHCP租约可以立即解决问题。在未重新启动防火墙的情况下更新DHCP租约失败。

在这两个防火墙上都启用了“保持活动”。

显然，在某种程度上的不活动之后，IP地址将过期。有人能帮我弄清楚这件事吗？

编辑获取更多信息:此时，我已经确定远程站点上的IP地址在正常运行8小时后就会失败。日志表明ARP数据包在这段时间内出现故障。重申，即使在8小时之后，隧道在两个防火墙上都是稳定的，只有DHCP分配的IP地址丢失。我今天早上7:45重新启动了远程防火墙，让他们修复连接，所以我将在4:45接到他们的另一个电话，告诉我他们的互联网坏了。

Answer 1

感谢每一个提供故障排除的人。以下是解决我的问题的方法：

远程办公防火墙配置有冲突的设置。一方面，它应该通过防火墙从我的公司DHCP服务器获取和分发IP地址。另一方面，它被配置为在隧道失败时提供本地IP地址。

经过更多的调查后，我得出的结论是，远程客户端在我上次重新启动防火墙的8小时后丢失了他们的IP地址。8小时是28,800秒，即IPSec隧道的默认生存期。

基本上，每8小时，这两个防火墙就会重新协商它们的加密。重新协商将花费超过2秒的时间，远程防火墙会认为隧道被破坏，并试图向其客户端发送本地IP地址。隧道协商将在几秒钟后成功，隧道两端都会很强，但是远程客户端将具有无效的IP地址。

Answer 2

169.X.Y.Z APIPA地址只会由于您的计算机和DHCP服务器之间缺乏连接而出现。

一个快速的解决方法(但不是没有问题)可能是在诊断问题时简单地配置静态地址。

为了进行诊断，我会抓取一台有问题的计算机，并在监视防火墙日志的同时更新IP地址。或者，在用户到达或系统更新DHCP租约时，只需检查防火墙日志。

Answer 3

虽然我不知道为什么会出现问题，但我建议通过让远程设备处理整个DHCP范围中的指定部分来拆分DHCP。这还将在站点之间出现连接问题时提供一些备份，至少可以保持远程网络的正常运行。