Installed CFP: now can't log onto AD domain

Hi there -

Version: Comodo Firewall Pro
Internet Connection: ADSL behind Cisco router
OS: WinXP Pro SP2, Windows Updates all applied (to date)
Logon: Windows 2000 AD Domain, account has local admin rights
Other Relevant Software: None that I am aware of
Custom Rules: See Below

After installing CFP3, I can no longer log onto our Win2K Active Directory domain. After entering my credentials, I am left with a blank background for several minutes. Finally, I get a popup that says “Loading your personal settings…” that looks like it will never go away (I left it and it was still loading my personal settings 35 minutes later). Usually I log on in about 20 seconds flat.

I have tried:

  • Entering “Allow in, LAN → Any” and “Allow out, Any → Any” type rules into the Network Security Policy / Global Rules, and placing them first in the list
  • Turning off “Do protocol analysis” in Firewall / Advanced / Attack Detection Settings / Miscellaneous

I had to do both of these things in Safe Mode… neither of them had any appreciable effect. I note that in v2.4, turning off protocol analysis did fix this problem… not so in v3.

The only way I could get the PC to log on was to turn the firewall off (move the slider to “Disabled”).

I’ve had to uninstall the firewall in Safe Mode to post this topic, so bear with me… getting further information isn’t going to be quick or painless, but I’m willing to reinstall if it helps resolve this issue.



Two suggestions: uncheck the Balloon pop-ups:Miscellaneous>Settings>General - uncheck “Show the Balloon Messages”. These stay up for a few seconds and if there are a lot of them, it can look like the system is frozen. I don’t think that this is the cause of your problem. What is the range of addresses for your LAN? Your router will be an address like, so the range has to include it. So far, I am just groping in the dark. The other suggestion (if the LAN address issue is bogus) is to try putting both the Firewall and Defense+ into Training Mode: Firewall>Advanced>Firewall Behavior Settings - and select Training Mode & Defense+>Advanced>Defense+ Settings - and select Training Mode. The problem may arise from a program accessing the Network (you LAN) that does not have permission from Defense+.

Thanks for your reply, AnotherOne. Disabling “Show Balloon Messages” did not help. I already had a global rule that allowed all inbound and outbound traffic to/from the entire subnet, including the router and all domain controllers. However, your post got me thinking, and these are the steps I followed…

  • With the Firewall Security Level DISABLED, Defense+ Security Level DISABLED and “Do Protocol Analysis” OFF, the logon process was fine. After logon, I got a popup saying that a new LAN was detected, which I trusted. This appeared to create similar global rules to the ones I already manually put in place
  • With the Firewall Security Level DISABLED, Defense+ Security Level DISABLED and “Do Protocol Analysis” ON, the logon process hung.
  • Turning “Do Protocol Analysis” back OFF and changing the Firewall Security Level to “Train with Safe Mode”, the logon process hung.
  • Changing the Firewall Security Level to “Training Mode”, the logon process was fine. I got lots of popups about CFP learning stuff. I did some normal activity and let CFP do some learning.
  • I then changed the Firewall Security Level to “Train with Safe Mode”, rebooted and logged on - it was fine.
  • I then changed the Defense+ Security Level to “Train with Safe Mode”, rebooted and logged on - again, it was fine.

So, it seems that the problem happens when either Protocol Analysis is on, or the Firewall is on with insufficient “learning”.

Interestingly, while going through the above procedures, I think I figured out at what point CFP kills the logon process… I think it is something to do with the application of machine group policy. Our domain does a few things with group policy - nothing too fancy, though. If the developers wish me to do further testing for them in a live working AD environment, I’m more than happy to help.

So, I think I now have a working solution… But it was a bit of a struggle to get there! I find it hard to believe that there aren’t other users on AD Domains that haven’t had similar issues… Are there any?

Perhaps the install procedure need to be a little more careful with its default settings in the case of a computer that is part of an AD Domain…

I hope this helps others.

Glad to be of help! (:TNG) Seriously, congrats on tracking down the solution to the problem.


yes there are others. CPF3 killed my Logon-Process and kills my Explorer while trying to see the Drives (maybe trying to connect to our multiple AD-Networkdrives).

So I killed CPF3 and gone back to CPF2.4 on my Notebook. Trying CPF3 again if it gets solved.



Thanks, but really I can only consider this to be a kludgy workaround rather than a solution… At best, I’ve just identified and bypassed the problem areas.

I am interested in helping the developers resolve this more elegantly (hint hint) :wink: Ready and waiting, just tell me what you need!

Turning off blocking fragmented packets fixed this on one client.

I had group policy errors on another also fixed by unblocking fragmented packets.

In version 3 checking to DISABLE them actually seems to ENABLE them… This is a bug that i’m hoping they fix :slight_smile:


I’m experiencing also problems while logging on to the corporate Active Directory Domain. The logon procedure takes +10 minutes with comodo on while normally its ready within one minute.

Tried the suggested workaround mentioned by Craigo, with no result. Even with the firewall and defense+ on ‘disabled’.

I also created some global rules wich allow all communication in any protocol to the domain controller, still without any result. The only option is to uninstall CFP3, then the logon process is fine again.

Hope somebody can shed some light on this problem.

Check to see if you have a box checked: see Defense+>Common Tasks>Defense+ Settings
On that page, see if there is a check in the box labeled: “Block all the unknown requests if the application is closed.” That option will apply the policies of CFP even if it is disabled or shut down. If that is not checked, then I’ll have to look for plan B. If it is, try the work-around described by Craigo again after unchecking that box.