Dell laptop running XP SP3, fully patched. Comodo version 5.0.163652.1142, firewall only (no Comodo AV).
I have a problem that only began after I upgraded to version 5. On my laptop I have three profiles; one that loads as little as possible (programs, drivers, etc), one that I use when working from home (that starts several programs, and loads drivers for the VPN), and one for when I’m at work (which loads most of the same programs as the previous profile, but no VPN client). After upgrading from version 4 to 5 the first two profiles still work fine, but the last one – the profile used in the office – will not load if the firewall is on.
My laptop boots properly. For the domain profile I’ll type in my account, password and domain, click OK and that’s it. The login dialog box gets dispatched, but nothing else happens. The hard drive activity indicator stays off, so there’s no disk activity. I’ve let the screen sit that way for over 10 minutes, but it never gets any further. I have to hit the power button to recover.
If I disable the Firewall and Defense+ I can load the domain profile without a single problem. I also tried putting both of them in Training Mode, but the exact same thing happens; the computer locks. Oddly enough, once the computer boots I can put the Firewall and Defense+ in Safe Mode and it will work just fine the entire day.
Absolutely nothing gets posted in the Firewall or Defense+ logs. There’s also no errors in the Application, Security or System event logs, which means I have no idea where to even begin.
I had been using version 4 quite a while and never experienced this issue, so I know it has something to do with version 5. But I’m at a loss to figure out how I can troubleshoot the problem. Does anyone have an idea bout how best to handle this situation?
You mention that if you disable the firewall and Defense+, the profile loads. Do they both need to be disabled, or does disabling say, just D+ do the trick?
It’s the FW. If I leave Defense+ in Safe mode, with the FW Disabled, it loads the profile just fine. If I Disable Defense+ and turn on the FW in any manner – even just Training mode – the profile will not load. I checked the Comodo logs again, but it’s still not posting a single message. Same for the Windows Event logs; nothing in Application, Security or System.
Thanks for the tip. I made the change, but won’t know if it helped for a couple of days because I’m on vacation. I’ll let you know as soon as I get back to the office.
If the block frag IP datagram thing works, ensure that your box is using MTU path discovery. That will require allowing in ICMP frag needed packets from gateway / router IP address on the network. However, due to security reasons those may be blocked by network admin, so you’ll need to investigate what MTU you should be using on the network. Apparently this is not an issue on the VPN.
Default MTU is 1500, but with MTU path discovery this can beome smaller. IF ICMP is blocked on the network then MTU path discover won’t work, ergo CIS v5 blocks your network connection. The only way this would be a problem if a non-standard MTU is being used, e.g., PPoe or sumpin (max MTU 1492).
SpeedGuide.net’s TCPOptimizer is a good tool to use in that regard.
However, if ICMP is blocked on the network then none of that will work. In my case, PPoE, I have MTU set at 1492, and allow ICMP frag needed in from anywhere, and out to modem and echo request in from modem. I allow ICMP out port unreachable, echo reply and frag need out to trusted dest only, i.e., modem & CIS servers. I block all in/out ICMP otherwise. I log all ICMP out not explicitely allowed. ICMP code 3 type 3 outbound is a sign that something is going on that needs to be addressed. That’s how I found out about needing to let ICMP port unreachable to CIS servers. Hey, if you can’t trust CIS servers what can be trusted?
MTU can plausibly get smaller only when surfing the cloud (router to router hops on internet). On a LAN segment or between LAN subnets, MTU shouldn’t change ever unless the network is misconfigured (either at particular routers or servers on the network).
However, if ICMP frag needed isn’t allowed on the network, that’ll mess up MTU discovery during nromal TCP/IP port 80 traffic. So the netwok may be configured for worst case MTU, e.g., 768 or 1024 or sumpin and that’s it (all routers handling TCP in the cloud have to step down to the network’s MTU). While there’s a bit of additional overhead to process smaller packets, it offers the best latency during periods of high congestion in the cloud (better chance of smaller packets getting routed someway). Larger packts less overhead, but greater chance of packet loss. Lot of different strategies in that regard.
But one thing certain: ICMP is evil and should be locked down for any org that doesn’t want its internal network infrastructure probed.
That does bring to mind an additional question though… is this a new setting for 5.x that wasn’t in 4.x? Or was this feature changed in some significant manner? When I upgraded from version 4 to 5 I used my previous configuration, so everything should have been set the same. That’s why I was so surprised when I came across this problem, because version 4 was working just fine.
I don’t recall there being changes compared to v4 for this setting. Just took a look at change logs of v5 of the final, test and mod versions. Almost all of the changes were about D+, AV and cloud.