Problems with acquiring or renewing the IP address

[Guest]

[pandlouk]

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 Security -> Advanced -> Advanced Attack Detection and Prevention -> Configure -> Miscelanous

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

[Little Mac]

Pandlouk,

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

LM

[pandlouk]

Pandlouk,

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

LM

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. http://forums.comodo.com/index.php/topic,6335.msg49501.html#msg49501

[Little Mac]

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

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.

LM

[MitchA]

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

[gustav]

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 = 192.168.0.77, Port = bootp(67))
Protocol: UDP Incoming
Source: 192.168.0.77:dhcp(68)
Destination: 255.255.255.255:bootp(67)

and at the same time

Date/Time :2007-03-07 16:54:53
Severity :Low
Reporter :Network Monitor
Description: Information (Access Granted, IP = 192.168.0.77, Port = bootp(67))
Protocol: UDP Incoming
Source: 192.168.0.77:dhcp(68)
Destination: 255.255.255.255:bootp(67)
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 = 192.168.0.1, Port = bootp(67))
Protocol: UDP Outgoing
Source: 192.168.0.251:dhcp(68)
Destination: 192.168.0.1:bootp(67)
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

[Little Mac]

gustav,

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.

LM

[pandlouk]

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

and at the same time

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

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

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

Also, I don't believe I've ever seen a Severity warning at Low level.  The first is medium, the second is low.

Low security are the allow rules when they are logged.

[gustav]

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.

[panic]

G'day all,

Question out of left field - if Gustav's first alert was as a result of a broadcast message sent to 255.255.255.255:67 by 192.168.0.77:68, as an address of 255.255.255.255 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 : 255.255.255.255
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?

Cheers,
Ewen :-)

[willas00]

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

[pepoluan]

Hi!

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 )

[Little Mac]

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?

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.

LM

[gustav]

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 0.0.0.0 to 255.255.255.255, 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)

[willas00]

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 : 255.255.255.255
Source Port : 68
Destination Port : 67

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

[Tags:]