I just un-installed Comodo 3.x for the 3rd time. ??? I have been a network administrator since 80’s and I simply cannot make it work properly on Windows XP Professional clients that are joined to a Windows 2003 Server Domain over a VPN tunnel. I do not think the VPN tunnel aspect has anything to do with it, but it may.
With Zone Alarm I simply need clients to “trust” a range of IPs that include the windows server, exchange sever, and the clients on that side of tunnel that I want the remote clients to be able to communicate and share files with. And to share files on the non-server side of the tunnel, simple add a “trust” range of IPs on that subnet. The authentication is done on both sides of VPN by windows server.
With and without Zone Alarm as configured above, connecting to the exchange server over VPN with Outlook works, as does Explorer browsing (whether to server, or other machines that have sharing enabled). However, once I install Comodo the ONLY thing that still work is browsing to the server with Explorer. If anything at all pop ups with other functions/attempts, it is a windows logon prompt, which thereafter refuses login and password saying that the client user is already logged in with those credentials on DC and that has been tried. And as I stated above, uninstalling Comodo restores full functionality so it is clear some type of Comodo blocking that is causing the problems.
I have tried adding General Rules as stated in a number of threads to no avail. I also set up two network ranges of addresses (domain side, and remote VPN side) AND then with Port Wizard had both Zones “trusted.” I see no block messages, and cannot figure out how to turn them on. I also seen a few mentions of other “wizards” (I think) but have not figured found any.
I am no novice to the network issues involved, BUT am ready to totally give up on Comodo and live with Zone Alarm which likes to BSOD (something Comodo has not done once) every once in while (or start saying some component will not verify for no reason whatsoever, requiring reinstall) or God-forbid, just switch over everything to Windows Firewall so at least I have something that works and is stable (albeit less secure).
I’m not professional as you are, but will try to help (and this is possible if Comodo Firewall (CF) just blocking something according to its configuration).
Are you using 3.0.25 version?
Try to get appropriate firewall logs: look into “view firewall events” (under gui window) just after connection (when CF may has blocked something).
If CF blocked outgoing connection from host where CF is installed then try to create appropriate ruleset for related application/process under application rules.
If CF blocked incoming connection, try to delete global rules (export your current CF config beforehand to be able to restore it when needed) and create appropriate ruleset for related application/process under application rules.
If you encounter difficulties creating rulesets, provide us CF logs about blocked connections, we’ll try to help if possible.
If nothing appears in CF logs, make sure 6 options under firewall->advanced->attack detection settings are unchecked.
If unchecking options doesn’t help, check if disabling/enabling option “this computer is an internet connection gateway” under firewall->advanced->firewall behavior settings makes any difference.
I tried reinstalling another time last night. Afterwards I was able to browse Windows 2003 Server AND Windows XP Prof. clients on other side of hardware VPN tunnel (both sides have VPN/Firewall Router)! And the Outlook to Exchange Server connection also worked.
However, come this morning it was no longer working. Tried rebooting, “ipconfig /release”, “arp -d *”, “ipconfig /flushdns”, “ipconfig /registerdns”, and various other VPN Tunnel/Windows Server tricks (not necessarily in stated order) that are sometimes necessary to help buggy Windows XP clients restablish full connectivity with server and domain controller over VPN connections.
Nevertheless, I think I found a bug, and perhaps a solution. Seems that the Global Rules network that I kept adding (i.e., the Windows and Exchange Server domain side of VPN) mysteriously keep disappearing whenever I rebooted. And I think that the only way that I have been able to get anything other than the local subnet (i.e., the trusted range on remote side of VPN) and Loopback Zone to stick is to use the Stealth Port Wizard to set up a range (actually, now that I think about it, I may not have rebooted so that may disappear (will have to test after this post)).
Additionally, I tried unchecking everything as per suggestion and that did not help the log to start reporting anything. It has never resported a single event. Which might not be unusually since the test machine is behind a hardware firewall which rejects all unsolicited inbound connection attempts. And, perhaps unchecking the ICS box has helped (hard to tell since I changes more than just that setting).
You should be able to duplicate the Named Zones disappearing. It may be VPN related since your adding a non-local subnet, who knows. I will see if specifying the actual ip ranges in rules instead of using named Zones (with IP ranges) keeps things working on this end.
Additionally, when CFP 3 does allow the Outlook to Exchange Server over VPN connection to work, the server will prompts for domain login credentials (which are accepted) before the connection is established. However, if I close it and then restart I will see alot of UDP and TCPs established with Server (which is the AD, DC, DNS for all machines (DHCP is via each of the VPN/Firewall/Routers)) but the outlook <-> exchange connection is not reestablished.
I have trusted lsass.exe, appInch.exe, inetinfo.exe, alg.exe, and svchost.exe all in an effort to track down the problem(s).
Also appInch.exe keeps coming up as something needing to be reviewed over and over. The app is copied from server each time a reboot and relogin occur and although I added it as trusted a number of time, the prompt still appearing.
I have the two ranges (domain side computers, and remote non-domain side computers of VPN) allowing IP Protocol: ANY for each. I do not see any blocking of UDP and TCP connection between client and server appear in Active Connections.
I am getting real close to giving up on this CFP for good if no one has a solution. Once a client computer and user have been authenticated everything should be working unless the VPN tunnel temporarily goes down for some reason.
Turning off “Blocked Fragmented IP Datagrams” in Firewall>>Attack Detection Settings>>Miscellaneous was the cure.
Seems that having that option checked (which is the default option) was also running havoc with DNS Resolution across the hardware VPN Tunnel as well since I was noticing a lot of connections being opened to the alternate DNS before the fix. Since I unchecked the “Blocked Fragmented IP Datagrams” Explorer browsing to shares (both on server and clients on other side of VPN Tunnel), IExplorer Intranet connections, and DNS resolution (both internal and external (i.e., internet)) seem to be working perfectly.
Since the domains hardware Router/Firewalls/VPN boxes already block fragmented packets (although, apparently not over the VPN tunnels), I am left wondering whether the client machine’s exposure has been as compromised as the “Blocked Fragmented IP Datagrams” warnings might lead some to believe.
sded,
Tried the 3.0.24 option. It allowed the Zones to be saved past rebooting, AND when I allowed CFP to update itself to 3.0.25 the Zones stuck! As a result, it seems to me that the problem with 3.0.25 Zones may simply be related to creation.
Thanks to you both! Everything has been stable for about 2 weeks since the fixes. (:KWL)
I am now contemplating moving more of the client machines to CFP, and if that goes well then all of them if I can resolve 2 last issues: (1) appInch.exe keeps coming up as something needing to be reviewed over and over. The app is copied from server each time a reboot and relogin occur and although I added it as trusted a number of times, the prompt still appearing. (2) LogMeIn keeps experiencing GUI Errors, even though the machine can be remotely connected to and shows up on LogMeIn as Online.