The other day, I received a few complaints about users not being able to get an IP address on the network and encountered IP Conflict errors in my SonicWall event log. Upon investigating the issue, I noticed the DHCP server had plenty of holes in the allocated range, so something else fishy was going on. We are running SonicWall Pro 3060 handling DHCP for our network. In reviewing the SonicWall log, there were a number of IP Conflict Detected messages, and these were all of the missing IP Addresses, pointing at one MAC address. I tracked down that MAC to the virtual interface on our Windows Server 2003 RRAS server.

With over 40 IP addresses conflicting, and fewer than 10 users on the VPN at the time, something wasn’t right. To determine the IPs that RRAS is holding onto, do the following:

• Open up Routing and Remote Access under Administrative Tools
• Expand your server, expand IP Routing, and click on General
• Right click on any interface, and click Show IP Routing Table
• Any addresses showing up with an interface of Internal is one being held by RRAS

In my instance, I had 50 addresses in the list. The Microsoft KB article 216805 at http://support.microsoft.com/kb/216805/EN-US/ discusses the default behavior on how RRAS obtains IP addresses. By default, it will obtain IP addresses from your DHCP server in blocks of 10. The big issue here, is that it never wants to release them, even after the DHCP lease expires.

My solution was to carve out another range of IPs for the RRAS subnet and allow RRAS to handle DHCP on its own. There are ways to tune how the RRAS DHCP relay option works, but holding onto the IPs forever was simply unacceptable to me. To switch the IP allocation method in RRAS:

• Open up Routing and Remote Access under Administrative Tools
• Right click on your server, and click Properties
• Click on the IP tab
• Change the option from Dynamic Host Configuration (DHCP) to Static address pool
• Click Add, and configure a range of IPs to be used for RRAS, that is available on your network, and outside of the current DHCP scope

One word of caution, do this after-hours, or after notifying your users. Once you change this, RRAS will immediately flush out the ARP table without dropping the VPN tunnels. This leaves the users with tunnels showing connected, but not passing traffic.

Another quirk I ran into as the weather flared up this week and more employees worked from home, is that when adding a second range to the Static address pool, the RRAS service needs to be restarted so the server will actually issue IPs from the new pool. All users get disconnected as a result.

I really like the advanced features the SonicWall provides in the DHCP server, and having this separation between local and remote workers, will help keep things running smoothly. The RRAS server does a much better job of re-using IP addresses in a pool it is fully in control of managing.