Clients not getting IP addresses via DHCP from ICS pc..

Hi all,

I have created a trusted network to CPF for my home LAN. My pc uses WinXp ICS to share the internet connection to my home lan. Previously, when using another firewall, all my home LAN devices could get IP addresses from the ICS pc via dhcp. Now after installing comodo firewall, the devices connected to local lan do not get an IP anymore via dhcp. However everything works fine, if I manually configure the local lan devices. Is there some fix how to make dhcp work again?

Anyway, thanks for the great firewall! (R)

I am having similar problems with ICS and have been unable to get them resolved. I have DHCP turned off on the router, and it still is giving me fits. Sometimes it works, sometimes it doesn’t.,5460.0.html

If you had the ICS working prior to CFP, and there are no remains (registry entries, drivers, services, etc) of your previous firewall (these can cause odd problems), here’s all you should have to do with CFP to set it up:

Define a Zone (security/tasks/add a zone) to encompass the IP addresses of the computers sharing your connection. Add the Zone as a Trusted Network (security/tasks/define a new trusted network). This will create two rules in the Network Monitor; one Out, the other In. They will allow all traffic from your computer to the “LAN” and from the LAN to your computer.

That’s it. Since it allows all IP protocol, that should resolve all issues. If you block any Windows services from connecting, that may impact it. If you have any remains of the previous firewall, that may impact it. If your client computers get their IP addresses automatically (rather than static), that may impact it, as the Zone is based on a static-assignment of IP address.


PS: Be sure to reboot.

Thanks for the reply.

That is what I have done. I have set up the home LAN to trusted network, and there are these 2 new rules in the network monitor, IP in and IP out. After that the internet connection sharing works with static addresses, but not with dynamic ones. Yesterday I took a dump of the traffic from ICS PC with wireshark, and I could see the dhcp requests there. however i could not see any replies to these dhcp queries. When I put the firewall to allowed state for a while, everything worked. In the dump I could see dhcp requests and replies, and the clients were getting their IP’s nicely with dhcp. Do you have any other settings in mind that I could check?

Also one thing about the logs. When CPF is active and dhcp queries are made, nothing comes to log about any blocked connections.


Do you know what address your DHCP requests are being made to ? The reason I ask is that I have a wireless card in one of my PC’s that makes its DHCP requests to my router using the Limited Broadcast address i.e. I discovered this when I began tightening up the outbound network monitor rules for that PC and could not get an address assigned. The standard trusted zone setup that has been recommended did not include this address. Seems to me that your ICS/DHCP server may be blocking this request (inbound) if this were the case.

I’m not familiar with wireshark but it seems that Limited Broadcast address would have been captured in the dump and you could confirm this. You could also experiment with opening port 67 on your ICS computer by adding a new network monitor rule: Allow UDP In Source Any, Destination Any, Source Port Any, Destination port 67.



Birdman has a point on the 255.x.x.x issue; I have experienced the same problem at work, and had to modify my rules.

However, I think your situation is a straight shot to your statement:

Setting up a Zone in CFP is geared towards Static IP assignments, because it sets the range. When you define the Zone as a Trusted Network, it creates the two rules to allow all IP traffic to/from that Zone. So if the computer’s IP comes as Dynamic, and it falls outside the range of that Zone, then the Zone & Trusted Network combo does nothing but sit there looking pretty… :wink:

Being able to set the FW to Allow All and have it works just reinforces that scenario.

So a couple questions:

  1. Do you need to have Dynamic IPs on your computers, or can you set them Static? (if you don’t know how to set Static, we can do that)

  2. If they must be Dynamic, can you see a range that they always fall into? (we can always widen the range, or define multiple zones)


Thanks for the replies :slight_smile:

You are right. According to wireshark dumps, the dhcp discover requests are coming from IP and going to I added the rule you suggested, it still does not work completely, but it goes further according to wireshark. Previously I could only see dhcp discover messages in the dump. Now I see dhcp discover (client to ICS pc), dhcp offer (PC to client), dhcp request (client to PC), but that’s it… No dhcp ack for some reason. I guess this might be because of ARP queries. I compared the firewalled dump to the non-firewalled dump. The message sequence is the same except that after dhcp request, pc is sending an ARP request in the successful case. I can not see this ARP message in the not successful case. I can attach the wireshark (previously ethereal) dumps if needed…

There is a wireless access point in my home LAN. It’s an old access point and it does not have built-in dhcp server for wlan clients, so it is relying on PC to give it the needed IP addresses for wlan clients via DHCP. There is also a xbox mediacenter in my home LAN which I have been using to test this dhcp problem. About the IP address range, I use the default WinXp ICS range, But of course when the client is asking for a IP via dhcp, the client’s address is until it gets an IP from the dhcp server, and IP does not fit in that range…



If you set the Firewall to Allow All, then open the Activity/Connections tab. Then refresh your connection from the client computer, and watch in CFP’s Connections what happens… Make a note of the connections that are created when you get the successful DCHP lease.

Then create matching rules to allow that; move them to the top of the Network Monitor (all rules must be above the bottom Block All rule, in order to work, and in this case it would probably be best to have them at the top, so that no filtering is needed).



Glad we’re making headway.

If the monitoring the connections (per LM’s suggestion) doesn’t give you the insight you need another approach is to refer back to your most recent wireshark dump. Check the address the DHCP request (after DHCP offer) is going to and see if you have need another inbound rule to support this getting through to the ICS/DHCP server.

Lastly we’ve just been allowing port 67 to be open inbound without any specific source or destination addresses in the rule(s). If you go permanent with this approach you may want to tie this down e.g. destination = (255.x.x.x are non-routable) Maybe someone with some more expertise can weigh in on if leaving port 67 open is a vulnerability.


Thanks for the tip LM :slight_smile:

I tried that… but unfortunately I did not find anything useful…

Successful case
svchost.exe, UDP In/Out,,, 342B, 688B
The next connection is already a dns lookup for a rss feed.
svchost.exe, UDP In,,, 80B, 0B was the IP given out by dhcp server

Unsuccessful case
svchost.exe, UDP In/Out,,, 342B, 344B

In the unsuccessful case the bytes out value is half, compared to the successful case.

I added the rule birdman suggested and and also selected “create an alert if this rule is fired”. But nothing about this comes to the log. However the rule is working, when checked from wireshark dump, as the dhcp query goes further than without the rule…

If there are any other things that I could check/try, please tell me.


CFP doesn’t open ports, or hold them open. Some firewalls do, in order to give a “stealth” response, but CFP does not.

If you create a Network Monitor rule tied to a specific port, all the rule does is Allow (or Block) the specified IP Protocol, for the specified direction, to/from the specified IP Addresses, for the specified Ports. This will only be applied if an application tries to create a connection in the context of that rule, and the port will only be opened while the application is using it. For my situation, I only allow UDP Out (since the traffic/connection is generated/started by my computer) from to on the associated ports for each (as taken from the Connections tab); the In response will be allowed as part of the communication started by my computer.

At present, we can’t tie an Application to a Network rule. There are other ways to tighten it up, though, by creating a rule for the specific application that you want to use the Port, define the IP address, direction of traffic, etc (in the Application Monitor). Make sure that’s the only matching application rule.



Seems like all dhcp traffic is udp and between ports 67 and 68. Port 68 on client, and 67 on ICS PC. I tried allowing udp traffic to both ports, but no luck… In the message sequence in successful case, there is a ARP query before the dhcp ack is sent. I can not see this ARP query in the unsuccessful case. I don’t know if that is something relevant, but it is a difference in the dumps.

Thanks for the clarification :slight_smile:


Jake, will you do the following:

Open Network Monitor to full screen, and capture a screenshot. Save the screenshot as a jpeg file (you can use MS Paint if you have nothing else) and attach to your post under Additional Options. I’d like to see exactly how you have the rules set up; there’s no reason I can immediately think of why you should still be getting shot down, if your rules are set correctly.

And a question, after uninstalling your previous firewall (prior to installing CFP) did you run a registry cleaner to remove the remnants of the old firewall?


Here’s the screenshot attached…

Previously I was using the sygate free firewall. And if I remember correctly, I have not run any registry cleaner after the uninstallation of sygate… I will check the registry for any sygate entries. Thanks for the tip.


[attachment deleted by admin]

Sorry to post back, but the .png attachment is too poor of resolution to be able to see the details of IP, etc, what with the white background and all.

If you can isolate to the rules section (like you have already) and save as a jpeg, that generally seems to work better.




For me it looks fine, if you click on the thumbnail, it will open a new window with a bigger picture… But in that window, the image is scaled down. If you go over the new pic, the mouse pointer should change to a magnifying glass with a plus sign, and you should be to zoom the pic to 100% size. This is with firefox. Tell me if this does not work, and I’ll attach a jpeg version…


My apologies; I had to make some changes in FF… :-[

I will take a closer look…


Which computer are these rules from? Host or Client?

I’m thinking the rule needs to change…

I’m gonna reboot here to see how the traffic flows for my DHCP lease. I’ll be back in a bit…


These rules are from the host pc, running ICS and the dhcp server. There is no firewall on the client.


Sorry we’re stepping on each guys. (too many cooks…)

Jake77, I was afraid that COMODO might not capture what we needed in the connections. Change your destination in the new rule back to Any (from The reason is that I think that the destination will change after DHCP discovery.

Little Mac, I understand an application has to be using the port. In this case it is the DHCP server in svchost. Regarding port 67 inbound vulnerability the question is could an LSP type trojan (which avoids the Application Monitor) listen in on port 67 (yes ?) and would tying port 67 to a non-routable address (e.g., 192.168.x.x) prevent instructions to this trojan from coming across the internet (yes ?).

Here’s a link describing how an LSP trojan works:

If we continue we should probably take this to another thread.