One of our Windows XP SP3 machines cannot renew its IP address from the DHCP server. Using CIS 3.9.xxxxx.509. Long ago a poster suggested using training mode to let CIS figure it out, but that didn’t work, so I set up two global rules as recommended in an earlier post:
Thus, it may be better (from a security standpoint) to create two rules, similar to what wodow posted, something like this:
Action: Allow
Protocol: UDP (it will only be UDP)
Direction: Out
Source IP: Any
Dest. IP: Any
Source Port: 67
Dest. Port: 68
Action: Allow
Protocol: UDP
Direction: In
Source IP: Your DHCP Server’s IP address
Dest IP: Any
Source Port: 68
Dest. Port: 67
For the inbound connection aspect of it, the DHCP server’s IP should remain constant; on the initial outbound, you may notice address fluctuation until the lease is established. This is why the outbound rule has “Any” for the Source and Destination IP, but the DHCP server IP as the Source IP on the Inbound rule.
I had the same problem and the following text is what Ronnie advised me to do and it solved my problem.
I would create the following rule to allow the DHCP traffic.
First create a rule on the “Global rule” Tab, open the GUI, Firewall, Advanced, Network Security Policy, Switch to the Global rules tab. Click on the top rule and press the [ADD] button.
Action: Allow
Protocol: UDP
Direction: In/Out
Source: Any
Destination: Any
Source port: Range Start Port 67 End Port 68
Destination port: Range Start Port 67 End Port 68
You could use the “log” option if you like to see if it matches.
And then press [Apply]. Drag the rule to the top and apply the policy pressing the [Apply] Button.
Still no joy. It doesn’t seem possible to me that DHCP is so difficult. What else can be wrong. The rule is the first Global Rule. What could be overriding it? Thanks.
I don’t understand why it isn’t working for you it works for me ok in v3.9 and also previously in v3.8 and v3.5. My operating system is Windows Home Edition XP SP3 kept up to date via Windows Update. I have Comodo set at ProActive Security, AV=Statefull, Firewall=Safemode, Defence+=Safemode.
Since v3.5 I have visited the Forums here immediately after installing Comodo CIS and set the Firewall and Defence+ exactly as it is advised in Kyles tutorials found in the Guides section at this forums. I then set the rule the same as stated in my previous post above and set svchost.exe to outgoing only. I also set my browsers as such and my trusted applications etc. Here is a screen shot from my Firewall today showing the allowed and blocked entries.
From what I’ve found in my searches,if you change your rules for svchost to allow incoming from the dhcp server to the affected machine, it may solve the problem.
3 first one entries are IP rages (My LAN, Secondary LAN, Multicast IP space) the next 2 DNS IPs. Make sure to include the Server IP if it’s static or a range of probable IPs if it’s dynamic.
I have noted that when WinXP (SP3) get the DHCP info access a number of IP addresses including the multicast range, so this maybe the problems, you don’t let WinXP properly initialize the DHCP protocol. Here are my App. & Global Rules I use. I hope it helps, good luck.
[Edit] I have changed the rule order for ‘System’ in the Apps Rules since it was too open.
Unless you disable the DHCP service in services.msc, svchost.exe is responsible for handling all DHCP transactions. With this in mind, you will need a rule for svchost.exe under Application Rules. The rule I use is:
Allow: UDP Out
Source Address: Any
Destination Address: 255.255.255.255
Source Port: 68
Destination Port: 67
If you use a fixed IP address for your DHCP server you could replace the Destination address with that, I would recommend, however, that you leave it as I have indicated.
Global Rule requirements will depend on what ever other Global rules you currently use.
I feel your pain! I have struggled with DHCP issues in multiple firewalls using WIN XP Pro SP3. The issue is not unique to Comodo.
Have you tried/researched the following:
Are you sure the XP DHCP client service is started? If it is not, it could be hosed from a prior AV/firewall/etc. uninstall. Older vers. of Symantec/Norton were famous for this. If not started, check on what the service depends on in the XP registry. It should just be TCPIP if yours is a stand alone machine. If you see old uninstalled software refs in that HKLM\System\CurrentControlSet\DHCP key, it has to be deleted. Also check HKLM\System\CurrentControlSet\NetBT for the same situation.
I saw an old Comodo forum post from 2/26/2007 to disable Protocol Analysis for DHCP issues. The setting is in Attack Detection Settings - Miscellaneous tab. Obviously this refered to an older ver. of Comodo but worth a try.
This is a pointer in the right direction tip since I can’t find my ref. paperwork.
I did some research on this issue a while back and found out MS modified the boostrap logic in SP3. In a nutshell, the boot process will wait a certain period of time for the XP firewall to start before the network connection is enabled. Additional some AV’s do the same thing. This is fairly well known. What isn’t well known is the time delay occurs even if you have the XP firewall disabled. Sometimes this causes DHCP to permanently time out or to assign the AIPPA IP address.
For example, I get a warning in my XP sysytem log every time I boot that DHCP has timed out. However, my Netopia router settings will keep retrying until the DHCP address renew is sucessfull.
Check out TCP/IP and NBT config. parms. for WIN XP, Microsoft Support. I think you have to add one of the optional NBT parms. to the registry. I did find a ref. on the web of a way to modify the bootstrap timing via registry mods but didn’t save the link.
I thought this might be related to your problem so I experimented on my XP SP3 PC.
I am behind a behind a Netopia 3347 modem/router and have it set to NAT, statefull inspection, with it’s hardware firewall stealthing all my ports.
When I installed the Comodo firewall (that’s all I am using) I noticed that it enabled the ICS setting on the Alert Settings tab in Firewall Behavior Settings. I turned that off and noticed that my dynamic DHCP was failing at boot time with APIPA address being assigned. This was not a problem for me aside from a slow network connection being established since the Netopia will keep trying to establish dynamic DHCP. When I turned ICS back on in Comodo, I was immediately able to establish dynamic DHCP at boot time. I also verified this by reviewing the Comodo firewall logs and did indeed see the BootP port 67, 68 entry in the log with ICS enabled.
So set on the ICS setting and see if that helps. After all a router is a ICS gateway and your DHCP server when using TCP/IP in dynamic mode.
Thanks, Don,
I have looked at a couple of your suggestions but I haven’t had time to really dig into it. I hope to this weekend. I appreciate the help and I’ll report what I learn.
I added the bootp udp rule bluesjunior suggested and it cleared up all my DHCP problems. The rule has to added as a sub-rule to your existing svchost.exe application rule. Once added, then move it up so it’s the first sub-rule under the svchost.exe rule. Leave the existing ip all … sub-rule under svchost.exe as is.
I tried initially to add the above bootp rule to the global rules but it didn’t resolve the DHCP problem. As another forum poster commented, it is svchost.exe that issues the bootp port 68 67 logic at XP boot time.
What I additional did was create a new network zone and added my ISP primary and secondary IPs to that zone. I then modified the DHCP UDP rule I added under svchost.exe to referenece that ISP zone. That allowed the UDP bootps entry to appear in my log. What is strange is the source shows 0.0.0.0 and the destination 255.255.255.255 for the svchost.exe log entry. I have to assume that Comodo’s stealth processing is doing that?
What I am wondering is I should add a similar rule under svchost.exe for DNS port 53 for the ISP IPs but I am not sure of this since I am browsing just fine using IE7.
After playing around for a week, I finally found the problem on my WIN XP SP3 PC with DHCP.
The NetBIOS setting in the WINS section in TCP/IP was set to default - acquire netbios from DHCP server. For some unknown reason at this time, this must not be working on the DCHP server on my Netopio 3347. Once I changed the option to NetBIOS over TCP/IP, I was able to acquire a DHCP lease with no problems.
My next step is to convert to WINS since NetBIOS over TCP/IP is not very secure.
If you are obtaining your IP address from your ISP servers, you do not need to have NetBT enabled. In most circumstances disabling NetBT on the adapter that connects is highly recommended. Likewise blocking NetBIOS ports to the Internet.
If you are using a private DHCP server, you still do not need WINS.
The only DHCP server I have is the one on my Netopia router. It appears that this device is not properly handling NetBIOS. This was confirmed by the fact that regardless of which firewall I have used including XP’s SP 2 - 3 ones, DHCP was not being set up properly when I selected the TCP/IP - WINS- NetBIOS default option. Additionally the default option does not assign XP’s NetBIOS as a fallback as it states; at least on my PC.
As far as I know, DHCP requires NetBios to properly initialize. This has been verified in the past when I turned it off via the TCP/IP - WINS - option in XP.
Therefore, the only option I have found to work is to select the “Use NetBIOS” option via TCP/IP - WINS section.
There appears to be a bug in XP SP3 as it applies to DHCP.
DonZ. DHCP has absolutely nothing to do with NetBIOS. Stop and think for one second. How do you think that all those operating systems out there that don’t have support for NetBIOS use DHCP?
NetBIOS is used in Windows Networks to facilitate communication between clients and servers. This goes back to the dark ages when Microsoft didn’t use TCPIP as its standard protocol, it used NetBIUE.
NetBIOS support in Windows revolves around broadcasting, resolving and connecting to other NetBIOS clients on a network.
WINS is a centralised way to store and retrieve NetBIOS related information and allows NetBIOS based networks to scale.
The only relationship DHCP has to WINS is it’s ability to send optional data as part of an offer datagram. That datagram may include information about WINS servers on a network, so that a client can register it’s NetBIOS information directly. This obviates the need to broadcast.
DHCP is an Internet standard protocol. It uses, for the most, part UDP multicasts. Essentially, a DHCP server ‘listens’ on the network for DHCP requests from clients. Clients typically locate an appropriate DHCP server by broadcasting a DHCP discover datagram using 255.255.255.255.
When a DHCP server receives this request a dialogue is established where the client and server ‘negotiate’ which data will be sent and received. This communication involves two ports 67 and 68 .
Bottom line, NetBIOS has no place on the Internet, in fact allowing access to your NetBIOS ports (137,138, 139 and I’ll include 445 too) is dangerous.
If you are having problems obtaining an IP address from your router, it’s either a IP communication problem or perhaps a hardware issue.
You are indeed correct. NetBIOS is not required for DHCP.
I think I know what happened in my case. Like I said previously, DHCP was not functioning correctly when I installed Comodo. It assigned 192.168.1.97/255.255.55.0 as my trusted Local Area Connection #1 network. Well that IP is in the range of DHCP addresses assigned by my router. This range is 192.168.1.1 - 192.168.1.253. I think something in DHCP and Comodo goes spastic when DHCP tries to assign an IP with the same one allocated to Comodo. I changed my Trusted Network Local Connection #1 IP range to 192.168.1.1 - 192.168.1.253 and that did the trick as far as DHCP leasing at boot time. I also added my LAN broadcast address range, 192.168.1.255/255.255.255.255, and the broadcast range for all my nViidia network mini-ports, 224.0.0.0 - 240.0.0.0. I do have uPnP turned off at the router so I am not worried about inbound 239. garbage.
Further rule detail is:
I have the global broadcast rule on top; outbound allow UDP any to 255.255.255.255 source port bootpc (68) dest. port bootps (67) .
For application rules, same above broadcast rule added to svchost.exe and right below it another rule, In/Out allow UDP my PC IP to 192.168.1.254/255.255.255.0(my router) source port bootpc (68) dest. port bootps (67).
Firewall running good presently and all those stupid port 137 and 138 firewall log entries are eliminated.
