Port 68/67 problems

[attrofy]

Howdy all,

We just installed a new server last week, running Win2k Server. We have about 38 machines on the network, and a sonicwall router handling our internet. Ever since we brought this server online, my log file has been filling up (between 5 & 7 entries per hour, 24 hours/day, every day) with the following log:

04/20/2003 00:02:51.912
- Denied UDP packet from LAN
- Source:192.168.X.X, 68, LAN
- Destination:255.255.255.255, 67, LAN - -

I have done some research and found that port 67/68 involve a request from the DHCP service on port 68, and port 67 is supposed to be the reply.

All of our machines are static IP based, but we do have DHCP enabled for network connectivity issues (i.e. printer ports, IP based copiers, phone system services, etc) however, there is currently nothing obtaining a dynamic lease.

Also, we are using our server for WINS and DNS resolution, by pointing our clients to the server's IP for those two protocols, and having the server point to an outside DNS server.

I have looked through the router's configuration, and the DHCP configuration, and don't see anything glaringly obvious. Also, since we use cable to connect to the internet, we do recieve a dynamic lease from our ISP. There has been no unusual leasing info on our internet IP address. WE recieve a new lease on a pretty consitant basis, and this pattern hasn't changed.

Any thoughts?

Thanks for your help.

 

[bcastner]

DHCP Lease Renewal

After 50% of the lease time has passed, the client will attempt to renew the lease with the original DHCP server that it obtained the lease from using a DHCPREQUEST message. Any time the client boots and the lease is 50% or more passed, the client will attempt to renew the lease.

At 87.5% of the lease completion, the client will attempt to contact any DHCP server for a new lease using a UDP 255.255.255.255 broadcast address. If the lease expires, the client will send a request as in the initial bootpc sequence when the client had no IP address. If this fails, the client TCP/IP stack will cease functioning.

If I was you I would permit the traffic on your firewall.
It is LAN-side, and not a security threat.

 

[manarth]

Your log:
04/20/2003 00:02:51.912
- Denied UDP packet from LAN
- Source:192.168.X.X, 68, LAN
- Destination:255.255.255.255, 67, LAN - -

Have you tried identifying the source? It may be worthwhile to find out what's trying to get a dynamic IP address.

<marc> i wonder what will happen if i press this...[ul][li]please give feedback on what works / what doesn't[/li][li]need some help? how to get a better answer: faq581-3339[/li][/ul]

 

[attrofy]

Thanks for the quick responses, bcastner that info is quite informative. I don't see anyting I have in place denying the LAN form broadcasting this request. The trust is pretty well set up that all internal (LAN side) requests are permitted through the firewall.

Manarth,
The Source IP address is the IP address of the server (I &quot;X&quot;ed out the numbers). I am trying to figure out if there is a service or something else that would be requesting a lease? I don't understand why the server (which is the DC) would be broadcasting outside the LAN for lease info? Any thoughts on identifying the source (aside from manually checking everything that requires TCP/IP)??

 

[bcastner]

Its talking to your ISP.

 

[Comstocb]

You last response leads me to believe the new server is the culprit as you say the IP (192.168.x.x) is that of the new server. The log entries started when you brought the server online so that helps build a case against the new server. I would confirm that it is the new server by associating a MAC with the IP in the DHCP broadcast and then checking it against the MAC of the new server. You can get this by doing a traffic capture and catching the DHCP request or by looking in the FDB table in the Sonicwall router (if thats possible, don't know). If you have Network Monitor installed on the new server, you could just capture traffic leaving the server to see what, when, where, why the new server wants a DHCP address. Anyway, if you can confirm the new server is asking for a lease but the IP is statically assigned, I would think the server is mis-configured although I can not think of any senario off hand that would cause this kind of behavior.

Brian

 

[manarth]

A client sends out a request TO a server IP on port 67, the server replies TO port 68.

It looks like it's your server is asking for an IP address renewal (and not receiving one). As the problem began when you added the server, this does make sense.

BTW, it's not trying to get outside the LAN particularly - the destination IP 255.255.255.255 just means broadcast to all IPs. Obviously these broadcasts shouldn't be routed to the internet (traffic overload!) so the firewall is correct to block it.

<marc> i wonder what will happen if i press this...[ul][li]please give feedback on what works / what doesn't[/li][li]need some help? how to get a better answer: faq581-3339[/li][/ul]

 

[attrofy]

Thanks again for all of the replies. These were my conclusions as well. Any good tools to monitor this sort of activity? Comstocb you had mentioned Network Monitor (I am assuming NetMon) anyhting else that that would be helpful for resolving these conflicts?

Thanks again for all of your inputs. Does anyone have any thoughts as to what exactly would cause the Server to think it needs a lease, if it already has a static IP? Any rouge services that would be that persistant in try to resolve a lease?