Mshen   23535 pts.  |   Apr 10 2009  6:34AM GMT

Alessandro, it does seem like the DHCP servers are only located on the LAN side.

ZBIIT   45 pts.  |   Apr 13 2009  3:33PM GMT

The DHCP servers are centralized on the LAN side. No servers are present on the WAN side and DHCP is turned off on all switches. The two sites are connected via a Point-to-Point T1 with a router sitting at each site. As for security, we have a SonicWall firewall and Symantec EndPoint Security.

We have 15 users at the remote site, non of which are experiencing any issues. The only users having issues obtaining an IP address automatically are those moving from LAN to WAN. As I previously mentioned it takes 60 - 90 minutes for those users to get an IP assigned to them. This time frame does not vary.

Is there any significance of the 60 - 90 minutes that can be expected like clockwork? It seems as though the IP handed out to each user is not expiring between travel from LAN to WAN. WIth a user having the issue, we can go from limited or no connectivity to manually assigning back to auto and it corrects the issue immediately.

Thought about the WAN router possibly blocking DHCP broadcasts but not the issue because the users do get assigned an IP, just not in a timely manner.

No changes have been made at either site that would create this issue.

Mshen   23535 pts.  |   Apr 13 2009  5:45PM GMT

Are your VPN routers configured as DHCP relays? If you are using Cisco equipment, use the IP helper-address command. Here’s a basic example:

ip forward-protocol udp

interface fastethernet 0/1
ip helper-address DHCP_SERVER_IP_ADDRESS

ZBIIT   45 pts.  |   Apr 13 2009  7:16PM GMT

The two sites are connected via PTP T1 not VPN. The routers are extremely old Motorola Vanguard 320s but we have never had a problem in the past. As I said before nothing has changed.

Mshen   23535 pts.  |   Apr 13 2009  9:14PM GMT

So I am assuming this is a 1.5Mbps Frame Relay connected directly to your trusted network, and the firewall does not play a part.

What happens when an WAN machine does an IPCONFIG /RELEASE and /RENEW. Does it get an address immediately?

Do you have voice and data going over this line? If you have QoS in place, your best effort packets may be dropping due to lack of bandwidth.

ZBIIT   45 pts.  |   Apr 13 2009  9:37PM GMT

Yes this is a 1.5Mbps Frame Relay directly connected to our trusted network and no our firewall does not take part. When doing an IPCONFIG /RELEASE and /RENEW it returns to limited or no connectivity. However, if I will manually assign the machine an IP it will accept it. If I change it back to automatic after manually assigning, all is good. Obviously I don’t want to have to do this but it does correct the issue, as it should. Voice and data are both going over this line. 16 channels for data and 8 for voice. We do not have QoS in place. Bandwidth has never been an issue.

Mshen   23535 pts.  |   Apr 13 2009  11:58PM GMT

It sounds like the DHCP broadcast requests aren’t going over the WAN to your DHCP servers. You can setup a basic DHCP server on your WAN side or do as I suggested before which was setup a DHCP relay over your WAN routers.

I don’t know how to setup a DHCP relay using your Vanguard 320 routers, but if you post the question, someone you may give you a good answer.

ZBIIT   45 pts.  |   Apr 14 2009  2:53PM GMT

They are going over the WAN, just not in a timely manner. 60 - 90 minutes to renew the IP. The problem is intermittent and typically happens after someone has worked on the LAN side for a good portion of the day and then moves to the WAN side. It has never happened in any other situation and doesn’t happen 100% of the time when moving from LAN to WAN. That’s what has made diagnosing the problem so difficult.

A basic DHCP server on the WAN side would resolve the issue but my problem is that we never had this issue before and nothing we have changed in our environment would create it. Simply put, we shouldn’t be having the issue whatsoever. That’s why I would like to actually figure it out rather than implement an additional server, basic or not.

Shouldn’t manually assigning an IP permanently to the users having the issue solve the problem?

The problem has occurred on a total of 5 users.