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
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.
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
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.
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.
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
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…
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 
Excellent! I’ll leave it at Any/Any and see if after a few days it starts going screwy again…
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…
What is the Solution to all of this? I get the same problem if my laptop goes into standby and occasionally when online using AOL or even IE7 I get disconnected from the wireless and then it reconnects as (Unsecured) and then bumps me off again a few times before it eventually after much hassle goes back to Secure connection. I’d hate to have to find another firewall if this problem persists and I don’t know of any firewall good enough to compare to comodo. I have got a copy of ZA Pro and Webroot Firewall but I don’t like either. Help Us!
Sorry if the last message sounded a bit in a panic. I’m just fed up of my wife complaining every other day that she’s been bumped off AOL and then my Wireless message says - "Connected to Sleepy Hollow (Unsecured) and then she’s let online again and then bumpted off two minutes later and this repeats a few times before it connects properly again. 
Eric
Ultimately, I dont’ think you should need any Network Rules for DHCP, as long as you’ve kept the default rules. The default rules will allow Outbound UDP, from Any IP to Any IP, on Any Port, and that’s what you need. The return contact is Allowed as an Inbound response to an Outbound request.
The key may be that you have Application Monitor rules for svchost.exe with parent services.exe to Allow the application Inbound traffic to Destination Port 68, and another rule to Allow Outbound to Destination Port 67.
That works fine for me.
LM
Greetings all.
Joined the forum to join in this “fray” . . . migrating from other firewalls, seemed pretty good until this “disconnection” thing. Bummer.
In my case, Comodo is on WinXp Pro SP2 operating as database and mail server for home LAN.
External firewall and DHCP is provided by another old machine running M0n0wall.
Internet Connection comes up disabled/limited functionality after some hours.
IP has changed - I know this because m0n0wall is setup to assign static IP using MAC address.
Trying a repair to get a correct IP fails - log shows all the same things you are reporting.
What does work is to close Comodo / go to allow all, repair the connection and restart/reset.
Funky workaround.
I have uninstalled - will retry shortly with all default options.
Anyone with any other bright ideas they want to try - this environment is not live, so you can play.
Robin
Jhb, South Africa.
Robin,
If switching to Allow All works to repair the connection, then 99% it’s a Network Monitor Rules issue. Other 1% is Application Monitor.
If you’ll post a screenshot (taken at full screen) of your Network Monitor (you can attach under Additional Options), that will help.
LM
Isn’t UDP a connection-less protocol? Therefore any replies to the outbound UDP has no correlated inbound packets, unlike TCP which is a connection oriented protocol.
That said, remember that DHCP replies (from the DHCP server to the DHCP client) is addressed to 255.255.255.255. I’ve seen some occasions which use 224.x.x.x, but I’m not quite sure why. Nevertheless, both address can be aggregated into an IP address/mask combination of 224.0.0.0/224.0.0.0.
Unfortunately I had already removed prior to taking screenshot of troubled system.
Have reinstalled with all defaults - as per “N00B install video”.
Now we wait . . . will only add the tweaks I added after some hours.
One step at a time.
[attachment deleted by admin]
Hi all… IT’s occurred to me that it might just be an AOL connectivity issue in my case instead of a Comodo problem. I know that AOL runs at a specific MTU so perhaps if I try changing the MTU from !500 to 1450 or whatever AOL Specifies that might fix the issued. Also, for some reason AOL really only likes WEP for it’s wireless security. I’ve been runing WPA-PSK TKIP instead of the suggested WEP by aol because I have about 7 neighbours with Wireless routers in range of where I live and a Signals Engineer living across the street. What I hate is that my Linksys WAG354G Wireless Internet Gateway doesn’t support WPA2!
Will keep you posted if problems persist.
Thanks for your patience.
Eric
Within the context of the DHCP lease renewal, the client computer will send a request to the host/server, and there’s a back-and-forth process that then occurs on those two ports. I have seen it logged as starting from 0.0.0.0, going to 255.255.255.255, as well as from the client IP to the host/server IP, and some other odd ones as well. Beats me as to why, but that’s what I’ve seen cause the renewal problems. There may be other things as well.
But in the context of Network Rules, all that should be needed is that default Outbound UDP rule (it’s actually a TCP/UDP rule…). Then just make sure svchost.exe is allowed to communicate on those ports (Application Monitor).
LM
Yes, you are right, re the UDP interaction between the client and the server.
What I was trying to say is:
TCP is connection oriented; you can easily differ between an attempt to open a connection – which has the SYN bit set to 1 in TCP’s header – with ongoing communication – which has the SYN bit reset to 0 and ACK bit set to 1. Furthermore, TCP packets have sequence numbers which indicates explicitly that it is part of a long string of TCP packets to be reassembled at the receiver (excepting extremely short communication which fits into a single TCP packet).
UDP is connectionless; every packet is treated as a monolithic unit of data. It depends on the application using the UDP to determine if a UDP packet is only part of a communication. There is no SYN, ACK or sequence number in the header of a UDP packet.
Therefore, even though there’s a back-and-forth communication between client and server in DHCP, there is no way for a computer to determine that a certain UDP packet is the reply of a prior UDP packet that it sent out; a computer must always assume that a received UDP packet is finished in its entirety, and has no relation whatsoever to prior UDP packets. It’s the job of the application to determine such relationship (which, in this case, the DHCP client daemon/service).
So, the only way to positively allow incoming DHCP packets from a DHCP server is by allowing Incoming UDP to port 67 (or 68, I keep forgetting which is which). Merely allowing Outbound UDP is not enough.