Seems like a stretch, but I’ll give it a try. Thanks!
My Defense+ security level is set to disabled already – so that’s not it.
Thanks; that explains it.
And on another part of this thread:
I tried this, but to no avail. I even removed the “No incoming ping” global rule, since there is no way to tell a global setting to “Ask.” Nothing has changed – the VPN appears to connect, but then dies while “Checking for banner text.” This is a common failure point for the Contivity VPN, and it typically means that the necessary VPN packets aren’t getting through.
I added a global rule that says allow IP protocol 50 IN/OUT from anywhere. But I’m still seeing unsolicited protocol 50 packets being blocked. In desperation, I tried adding a global rule that says “permit all IP from anywhere,” and the connection still fails. But if I set the firewall mode to “disabled” I connect immediately.
So where else is there to look?
I’m not any kind of expert, but a quick look at a reference http://www.docs.hp.com/en/B9901-90021/ch07s04.html
shows that UDP and TCP need to be configured for this connection. That may be why it stops working.
IP (which is what I am allowing) includes both TCP/IP and UDP/IP, as well as ESP, GRE, ICMP, and a slew of other protocols. So I should be OK in that regard.
It begins to sound like your rules are not being followed. Try deleting all of the related rules and rebooting. Then start your connection and use the pop-up “Allow” dialogs to set the connection to “Trusted” for all queries. This will give you a broad Allow IP in/out anyanyanyany rule, but it should be fine if it is a program based rule.
Protocol 50 is IPSEC, and there is a setup description in this topic that may be of some help
https://forums.comodo.com/help_for_v3/enable_the_connection_help-t15591.0.html;msg107926#msg107926
With some topics merged together, I’m slightly confused as to what’s working for who. So, let me ask who is still having what kind of problem so I can get myself oriented properly.
I uninstalled CPF altogether, then reinstalled it. To keep things simple, I have run only three applications (not counting Comodo) – SecureCRT (SSH), Firefox, and myVPN client. I have allowed or trusted everything except spoolv (which does not enter into it; it has always been blocked). No luck.
I tried trusting the networked detected by the VPN client; it added the rules after the Block ICMP rule, which surprised me… After reordering these rules, I restarted Contivity – and was told that Firefox wanted to modify some VPN-related registry entries.
Up to now I haven’t seen this errant behavior in v3 – but apparently it still exists. 
The CPF docs say that incoming packets need to make it through the global rules first, and then the application rules. I’m guessing that these packets are dying because Comodo doesn’t know where to send them, but that’s just a guess.
Thanks; I hadn’t seen this one. But it didn’t help.
I’m going to try two more things: I’ll uninstall Comodo, scrub my registry, and then reinstall. If that doesn’t do it, I’ll try it again, but allowing Comodo to be more trustful during the install. Maybe if it starts that way and then I tighten it up things will work better, though a non-deterministic firewall is a worry, to say the least. I truly am impressed by the design of v3, but I may have to throw in the towel on this.
That being said, as long as CPF is on my system I’ll be happy to provide any information I can in order to help the folks there understand the problem. And of course, I’ll still take any suggestions offered on how I might get to the other side of this problem myself.
Try “Training Mode” for both the Firewall and Defense+ and see if that helps. Change to a more secure mode after running the applications that you need for a day or so.
Doing some digging back into my reference materials, IPSEC is really a combination of things. It uses two distinct protocols: ESP as protocol 50, AH as protocol 51, and ISAKMP exchange using UDP on port 500. If you’re running textbook style IPSEC, you’ll need to open up CFP for both protocols, and traffic on UDP/500.
Assuming things are running more or less as the texts says IPSEC should work, I’ll suggest starting with a Predefined Firewall Policy for a VPN. Click Firewall → Advanced, Predefined Policy, then Add. Give it a name, like IPSEC VPN. Then Add these rules:
First rule:
For protocol 50 ESP
Allow IP In&Out
Source any you probably want to limit this for security, but to get it working
Destination any set it for ‘any’ for now
IP Details custom 50
Next rule:
For Protocol 51 AH
Allow IP In&Out
Source any
Destination any
IP Details custom 51
Next rule:
for ISAKMP key exchange
Allow UDP In&Out
Source any
Destination any
Source port 500
Destination port 500
Then set up VPN client program to use this new predefined policy. It may be necessary to open up the Global Rules some to allow packets inbound. If things don’t work, that’ll be the next to try.
Note that some VPN’s will run L2TP inside an IPSEC tunnel. That’s an additional setup on top of this. Without a working IPSEC, it doesn’t matter. So one step at a time.
Thanks – this is a useful summary. I added ESP, AH, and ISAKMP to anywhere in my Global policies, along with GRE (probably not necessary, but it was mentioned elsewhere). My VPN client has “Allow Any IP To/From Anywhere.” I even tried adding a second rule “Allow TCP To/From Anywhere,” even though IP includes TCP and UDP. Maybe, I reasoned, IP means all IP except TCP/UDP. It didn’t help. I tried adding lsass.exe (also mentioned elsewhere) with the same two rules. No luck.
One other thing – since the last install (which included allowing Comodo to review its database for safe applications), I no longer get any logging. I have checked logging in all the global rules and the pertinent application rules, but there are no “Firewall Events.” (I even have “Monitor Other NDIS Protocols than TCP/IP” checked under miscellaneous attack detection settings.)
[–Edit–]
I turned off Defense plus again, and now I have logging working. I’m back to where I was — CPF is blocking IP 50 packets designated for “System Idle Process.”
[–End edit–]
Is there any way to register an application (under Windows XP Pro) to tell Windows that it wants to receive ESP packets?
Four more pieces of information:
-
If I disable the firewall, I can connect to the VPN. If I then change the firewall to training mode, I can actually log in an work on remote systems for about a minute. Then something times out and those blocked ESP packets rack up in my log - both in and out. The VPN doesn’t disconnect, but no packets can tunnel through.
-
When looking at data, I realize I had misread (and therefore misposted) the events associated with the problem. On initial connection, the firewall is blocking outgoing ESP packets (and not incoming as I first reported) ascribed to the System Idle Process. Still, the first item makes it clear that CPF will block packets in both directions.
-
The only traffic reported as coming from my VPN software is qotd (to their windows server) and ISAKMP. Neither of these are seen after the initial connection, though I suspect that the qotd packets are periodically re-issued.
[li]This is the most interesting fact of all, I think. As long as I keep typing into a terminal session, the connection doesn’t time out. It turns out that these ESP packets are keep-alives – exactly one minute from the time that I stop typing, the ESP packets are sent out and my connection freezes. Disabling keep-alives on my VPN client doesn’t help, since the other side still sends them. But at least I have a way to do a little work.
It appears that packets in either direction keep the connection up – so I set my terminal program to send NO-OPs every 30 seconds, and that seems to be working. I just have to remember to fire up a terminal session sometime during the first minute of my connection. But I still have to disable the firewall in order to connect, so this is a discomforting work-around at best.
In summary: The problem is still ESP packets from/to nowhere being blocked. These are required as part of the initial VPN connection, after which they seem to be keep-alives. Disabling CPF to make the VPN connection is a work-around, though a kludgy one.
It’s possible that ESP packets will be sent periodically even if the connection is active. If I recall how the Contivity VPN works, these go out every half-hour by default. (But it’s been a long time, so I’m not sure now.) If this happens, I expect to lose my connection on a regular basis. But it’s better than nothing.
I apologize for the long posts – but if you’ve gotten this far, thanks for listening. I hope this analysis will help the fine folks at Comodo zero in on a resolution.
Well been trying all good suggestions here without luck.
Still trying to connect through VPN (PPTP) and hanging when trying to send username/password getting error 619.
Just noticed this thread though
https://forums.comodo.com/help_for_v3/enable_the_connection_help-t15591.0.html;msg107926#msg107926
which I’ll look into.
Whatever the outcome for me then I really hope Comodo Team will consider an easier workaround on the VPN issue in next version/update.
Maybe… I’ll suggest trying this. In the Application Rules for “System”, add 3 rules: one for ESP and one for AH, allow in&out, from any source to any destination, and one rule for ISAKMP, allow UDP in&out, from any source to any destination, any source port, and destination port 500. That almost duplicates the policy suggestion I made a little earlier, but does it in the context of some existing rules. And then add those same 3 rules to the Global Rules. That should get the firewall out of the way. Should, and will, however can be different things. We need to find out which.
It may be necessary to add your VPN client to the Application Rules list, with the predefined policy of allowing all traffic as a “trusted application”.
Is Defense+ turned on? If so, then identify your VPN client as being a “trusted application”. I don’t have that much experience with Defense+ settings, but there are networking elements for DNS and loopback that are par of the D+ settings. That could have some effect.
Note that is there is some other protocol running within the IPSEC tunnel, things still may not work. Using the “allow all” approach should get past that. Settings can be tightened up later.
Let’s try this for a PPTP VPN connection.
In Global Rules, add this rule:
Allow TCP
Direction In&Out
Source Address any
Destination Address any
Source port any
Destination port 1723
and this rule:
Allow IP
Direction In&Out
Source any
Destination any
IP Details GRE
And under Application Settings for “System” (not System Idle Process, that’s something different)
add those two same rules ahead of the default blocking rule. That should allow the PPTP setup connections to happen. After the PPTP connection, there is some other stuff, but it breaks differently if it encounters a problem.
If things aren’t working, then I’ll ask that you look in the firewall logs, and see what’s there.
I’ve tried implementing the steps you suggest, but no luck. That is, I created rules for System; the other items were already in place. No luck, I’m afraid.
What’s more, I no longer have anything showing up in the log. I enabled logging in all the global rules and all the rules introduced for System, disabled Defense+, and enabled “Monitor other NDIS protocols”.
Adding these two rules both under Global Rules and under Application rules for “System” (ahead of the blocking rule) doesn’t work. No events are logged under View Firewall Events. Setting the firewall to Disabled and then trying to VPN still works.
We appreciate your hard work to get your vpn running. It hopefully will work soon…
It can hopefully help a lot of others.
A question.
Have you captured the traffic when the firewall is off, to see what protocols and such the VPN uses?
You can download and use Microsoft Network Monitor 3.1 and make a capture so you can analyze it after. Turn off the firewall, start the capture, and then start your VPN. When it’s finished you have some analyzing to do… 
I think it defaults to 20 Mb in size (the capture). I tried with 1 Mb and it finished pretty fast.
You can download it for free here:
http://www.microsoft.com/downloads/details.aspx?familyid=18b1d59d-f4d8-4213-8d17-2f6dde7d7aac&displaylang=en