Problems with acquiring or renewing the IP address

If you have a problem like:

  1. Connecting in internet with a modem
  2. Difficulties in acquiring the IP address (through the DCHP server)
  3. Renewing the IP address (through the DCHP server)
  4. Loosing connectivity

Try to disable the feature Do Protocol Analysis in CFP.

You will find it under SecurityAdvancedAdvanced Attack Detection and PreventionConfigureMiscelanous

ps. In some cases a reboot is needed for this to work.


For the sake of education, why would disabling protocol analysis aid in obtaining the DHCP lease?


Hi Little Mac,

It seems that with some network cards, modems, etc., the protocol analysis block some data from the dchp server. I do not know why though :-\ . Maybe Egemen could give us some information.

I suspected about this, since it gave problems with gprs,bluetooth, and wifi cards but thanks to willas00 I had the confermation about it.,6335.msg49501.html#msg49501

Hmm, I notice in the Help Files release notes that an issue with DHCP Lease Renewal/Stateful Packet Inspection was resolved for version

Perhaps it has been “un-resolved” or there is a new issue… Probably someone who is/was experiencing it needs to file a ticket with Support.


I just recently tried this and it really does help, lately my interent connection had been dropping arounf every 6 hours or so and evertyime it did there was a block entry in the log with an ip address & the dhcp port attached to it, now my connection is no longer dropping and I no longer see any dhcp blocked ips in the log

I have a similar problem, which does not seem to be resolved by disabling the protocol analysis, however as soon as I turn off the network monitor on my host computer the problem goes away. That said, I haven’t found any clues as to what is blocked, looking at several log entries, except perhaps this one

Date/Time :2007-03-07 16:54:53
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP =, Port = bootp(67))
Protocol: UDP Incoming

and at the same time

Date/Time :2007-03-07 16:54:53
Severity :Low
Reporter :Network Monitor
Description: Information (Access Granted, IP =, Port = bootp(67))
Protocol: UDP Incoming
Reason: Network Control Rule ID = 1

this seems to imply that the same rule allows and denies access

On my client computer I see the following entries

Date/Time :2007-03-08 14:40:33
Severity :Low
Reporter :Network Monitor
Description: Information (Access Granted, IP =, Port = bootp(67))
Protocol: UDP Outgoing
Reason: Network Control Rule ID = 1

even though it is not getting any Ip address.

I am totally mystified

P.S. this problem only started after the latest update of Comodo


I must say, " ??? ??? ??? " That makes no sense to me… How can one rule both allow & deny the exact same communication at the exact same time?

What’s odd to is that IP of the Outgoing message from the client is not the same IP listed in the Incoming message on the host.

Will you please open your Network Monitor to full screen, capture a screenshot, save it, and attach to your post under Additional Options. If you personal IP address shows in it, you can mask it out for privacy.


First time for me too. :o
I think that you just found a bug in CFP.

Low security are the allow rules when they are logged. :wink:

Here are the rules for my host ICS computer, although the rule number has changed, it is now number 3, allowing traffic in from my local network. It is definitely here the problem lies, because as soon as I turn off the network monitor, I can get a new IP address from the dhcp.

[attachment deleted by admin]

G’day all,

Question out of left field - if Gustav’s first alert was as a result of a broadcast message sent to by, as an address of is well outside the named range for his zone, would we need to make an explicit rule to allow traffic IN for the broadcast address?

I know previous versions handled the broadcast address as allowable, regardless of whether it had a NM rule or not, maybe this is what has changed in the latest version.

To test the theory, we need to make a NM rule with the following values :

Action : ALLOW
Direction : IN
Protocol : UDP
Source IP : ANY
Destination IP :
Source Port : 68
Destination Port : 67

Logging should be enabled for the duration of the test and this new rule should be rule 0 - at the very top of the list.

Do you think this would help? Or have I just made the waters muddier?

Ewen :slight_smile:

ive added that to the NM rules now mine is due to renew at 1700 UK Time so we shall see if that helps me. The TOP post worked for me fine but stoped working all of a sudden. Maybe this will work if not ill post logs 2night


Our school server, which is connected to Cable ISP, requires DHCP to get its IP address. DHCP always failed when Comodo is active. So I added some rules:

Allow UDP In/Out from [Any] to [Any] where source port is 67-68 and destination port is 67-68.

No problems with DHCP anymore.

( I know that is overkill, but our server is used as the DHCP server for the school’s internal network )

I think that’s worth a shot, Ewen. You may be right about the current version; I had not followed that train of thought back, although I know they made changes to the way it monitors and logs traffic.


I have tried most of these solutions, without success. If I turn off the network monitor I see the request for an IP address from to, as you can see from the connections shot attached, but I have not managed to get these rules to open up my firewall.

Paradoxically, even if I cannot renew my IP address, I can still connect to the internet if I am using one previously acquired, whose lease has not yet expired.

I can also share files and printers if I use a static Ip address (alternative configuration)

[attachment deleted by admin]

Did that it will went dead. in my other post ive posted logs!

I have been trying my hand with WIRESHARK, although it seems mostly Greek to me, however I have identified one transmission that seems to disappear when the Network Monitor is turned on, I’m attaching it as a pdf file. Modifying the rules a bit seem to allow DHCP offers to go through, but they don’t get accepted or acknowledged.

For now I will have to resort to turning off the NM while setting up my client to connect, but I hope another solution can be found.

[attachment deleted by admin]

Hello dudes,
tried both of the solutions (unchecking Do Protocol Analysis and adding some rules) but nothing works. Still loose connection after 1 hour, getting a 169… IP adress from Windows, which cannot be repaired.
Only thing left to do is to reboot.
However, yesterday came across another weird solution : when changing Security Level from Custom to Allow ALL, the IP-adress is repaired automatically for about another hour.

Any solutions ? :THNK Please ??? ???


If it works when you set the firewall to “Allow All”, then it’s a rule issue.

Try adding a Network Monitor rule with the following values.

Action : ALLOW
Direction : IN/OUT
Protocol : UDP
Source IP : ANY
Destination IP : The IP address of your DHCP server(usually your router)
(Source Port : A port range (67 - 68)
Destination Port : A port range (67 - 68)

This rule should be moved right to the top of the rules list. Reboot your PC and see if you can acquire an Ip address.

Let us know if this helps,
Ewen :slight_smile:

I have a laptop and connecting to a PC with CPF Pro, which has Internet Connection Sharing enabled over wireless. Adding rules or disabling protocl analysis does not help. If Allow All is set, everything works properly - I am able to renew my lease. So, basically, my laptop can not get an adress from DHCP running on computer with ICS. This rule has worked for me - but after a restart.

EDIT : Lost the ability to get the address from server after resuming from standby. So, it is not working here…

Gee… I just got the strangest experience.

I had just wiped out my production server (purposefully), reinstalled Windows 2003 and all kinds of softwares, and got a connection from the Cable Internet.

I installed CFP with the recommended automatic settings… and promptly lost all connections. Tried adding various rules, even resorting to ‘Allow All’ … still no connection. Uninstalled CFP, and got connection again.

But… I can’t live without CFP protecting my server!! :frowning:

So, I installed CFP again, this time not using the recommended automatic settings (i.e. doing everything manually), configured the necessary zones & rules & whathaveyou’s…
And I got my connection back! (With CFP happily protecting my server :BNC )