2

In my central office I have a SonicWALL NSA-2400 appliance acting as the hub for several remote offices. It is configured to pass DHCP requests to my internal DHCP server. The VPN connection works fine, IP addresses are distributed to remote offices as they should and I'm very pleased with the results - except for one remote office.

Last Friday I installed the little brother of the NSA-2400, the NSA-240 in a remote office. Both firewalls report rock solid connectivity at all times, and all aspects of network connectivity through the tunnel are working well. My problem is that so far, each morning the remote office will call and tell me they don't have any network access. In each case, they have lost their IP addresses handed out by my corporate office DHCP server and have been given "junk" 169.xxx addresses.

Restarting their firewall and renewing their DHCP lease fixes the problem immediately. Renewing the DHCP lease without first restarting their firewall fails.

Keep Alive is enabled on both firewalls.

Clearly after some amount of inactivity, the IP addresses are expiring. Can anybody shed some light on this for me?

EDIT FOR MORE INFORMATION: At this point I have determined that the IP addresses at the remote site fail after 8 hours of uptime. The logs indicate ARP packet failures around this time. To reiterate, even after the 8 hour mark, the tunnel is stable on both firewalls, only the DHCP-assigned IP addresses are lost. I restarted the remote firewall this morning at 7:45 and had them repair their connections, so I will be receiving another call from them at 4:45 telling me their internet is down.

Improve this question

4 Answers 4

Reset to default
2

The 169.X.Y.Z APIPA addresses would only be appearing as a result of a lack of connectivity between your computers and the DHCP server.

A quick workaround (but not without issues) might be to simply configure static addresses while you diagnose the problem.

To diagnose, I would grab one of the computers with the problem and renew the IP address while monitoring the firewall log. Or simply check the firewall log around when the users arrive, or when the systems renew their DHCP lease.

Improve this answer
1

While I don't know why your problem started occurring, I would suggest splitting your DHCP up by having the remote devices handle a designated segment of your overall DHCP scope. This would also provide some backup in the event of connectivity issues between sites, at least as far as keeping the remote networks running.

Improve this answer
0
1

Thanks to everyone who provided troubleshooting. Here was the solution to my problem:

The remote office firewall was configured with conflicting settings. On the one hand, it was supposed to acquire and distribute IP addresses from my corporate DHCP server through the firewall. On the other hand, it was configured to supply local IP addresses in the event the tunnel failed.

After more investigation, I concluded that the remote clients lost their IP addresses precisely 8 hours after the last time I rebooted their firewall. 8 hours is 28,800 seconds, or the default lifetime of an IPSec tunnel.

Basically, every 8 hours, the two firewalls would renegotiate their encryption. This renegotiation would take more than 2 seconds, and the remote firewall would think the tunnel was broken and try to hand out a local IP address to its clients. The tunnel negotiation would succeed a few seconds later, the tunnel would be strong on both ends, but the remote clients would have invalid IP addresses.

Improve this answer
0

On the Sonicwall support site there is a document site_to_site_vpn_troubleshooting_on_sonicwall_security_appliances.pdf

Provides steps in troublshooting this type of scenario.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .