Problems with acquiring or renewing the IP address

[gustav]

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]

[Dweez]

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 ?    Please 

[panic]

G'day,

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 :-)

[Radomir]

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...

[pepoluan™]

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!! 

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  )

[Little Mac]

Hmm, very interesting...  Normally, I've seen problems occur when someone does use the Advanced over Automatic install, most likely due to improper configuration somewhere along the way.

Odd to me that that would be the solution.  I would sure like to have seen if you got the same results twice on an Automatic install, before going Advanced.  Ah, well, such is life..

LM

[Dweez]

I'm sorry dudes,
after the 'debacle' with CAV (winlogon as falsepositive), now CPF is acting as if has a mind of its own.  I'm not looking to spend any more time on endless settings, improper updates or figuring out where something went wrong.
I'm still convinced that Comodo products have potential, but I only will retry them again when they are more stable.  In the meantime I'll settle for something else.

[Eric Cryptid]

Hi everyone,
   I just thought I'd add in my two pence here... When you install comodo and use the automatic settings it does not add your router as a trusted IP address. This needs to be done first thing after installing Comodo. If you goto Security and Tasks then click Define Trusted Network and then add a trusted IP. Since I use the default for my router.  I inpute 192.168.1.1 to 192.168.1.1 and call it "Home LAN"

Then click ok and go to the bottom of the tasks page and select "Add Trusted Network" and follow the screen instructions, not forgetting to choose the Trusted IP address you entered earlier which will be on the drop down list I think after you click NEXT once.

This trouble with DCHP use to be a problem with much earlier 2.0 versions and I think at the time we had to Uncheck "Do Protocol Analysis" and "Advanced protection against Trojan Protocols"

My best advice is to ensure your Router's IP address is set as trusted and is the first two rules of the Network Monitor and then if that still gives you problems uncheck BOTH "Do Protocol Analysis" and "Protection Against Trojan Protocols" and see if that resolves the issue.

I personally don't really seem to have this problem unless my laptop has gone to sleep overnight.

Hope this helps...

Eric

[pepoluan™]

Well, in my case, the Windows 2003 server is the router, i.e. it performs NAT for the internal network onto the public network of the cable internet provider.

I should add that this behavior in my case seems to be repeatable: I just recalled that I installed CFP with Automatic settings beforehand, assign a trusted zone, and left. Apparently the internal network cannot connect to the Internet even with Allow All. So the other admin -- in desperation, methinks -- uninstalled CFP. I installed it again, again with Automatic settings. And again connection to the Internet is gone. So I uninstalled, and installed again, with Manual settings.

[omniphil]

I'm getting the same issue here.  Can't get to dhcp.

home server (192.168.0.1) is running internet connection sharing and comodo. If I try to connect with the wifi in my cell phone to a wireless access point in the internal lan it wont get a dhcp address it end's up defaulting to a 169 address.  as soon as I set it to allow all, it get a dhcp address fine.

I tried doing the rule above with ports 67-68.
I tried making a rule that allows all tcp/udp/ip in/out with the source of the internet network zone to the external network zone.

I think the issue lies in the trusted network setup. If its trusted all traffic should be allowed.

Side note...  If I reboot the home server without making any changes to the OS or Comodo, it will start working again, but once dhcp gives out a particular IP address it will not work again once I disconnect the device with that IP and try to reconnect.

[Little Mac]

If you've created that port 67, 68 UDP network rule with the address of your DHCP server, try changing it to Any instead of the specific IP address(es).

See if that helps.

LM

[omniphil]

Yes, that did work!

Not sure I'm crazy about allowing Any/Any for that port, but it does work.
I went back and tried to enter a range of 192.168.0.0 - 192.168.0.255 and that didnt work, I also tried the outside IP of the machine, that didn't work either. So that brings up a wierd question, what IP address is it looking for that works in Any mode, but not work when I select the entire range?

The log wont show me unfortunately...

And again, If I reboot the home server without making any changes it works again too for a while...

If you've created that port 67, 68 UDP network rule with the address of your DHCP server, try changing it to Any instead of the specific IP address(es).

See if that helps.

LM

[panic]

G'day,

It's OK to allow ANY/ANY, as the routers DHCP will only ever apply autoassigned addresses within the IP range set up on the router. As they would have to be private addresses, they wouldn't last one hop outside your LAN before they were black holed (all private address ranges must be "swallowed" by routers with routable addresses).

Hope this helps,
Ewen :-)

[omniphil]

Excellent!  I'll leave it at Any/Any and see if after a few days it starts going screwy again...

G'day,

It's OK to allow ANY/ANY, as the routers DHCP will only ever apply autoassigned addresses within the IP range set up on the router. As they would have to be private addresses, they wouldn't last one hop outside your LAN before they were black holed (all private address ranges must be "swallowed" by routers with routable addresses).

Hope this helps,
Ewen :-)

[omniphil]

It did start going screwy again. when I added the Any/Any 67-68 rule it allowed my to get dhcp again. however after a few hours it stopped doing it again.  I'm also now noticing holes in the log when i log off of the server. I'm thinking that maybe I need to leave the workstation locked and not log off as this is what seems to be causing the odd behavior...  Comodo is installed as a service.  very odd...