Thanks for the sympathy. It has been wearing – and I’m afraid it’s taken more time from work than I have to spare.
That, and sheer stubbornness, are the reasons I continue to plug away at this.
As for packet capture, I’ve been using Wireshark. There is some discussion of it at the link below. In summary, the conversations are the same up to a point with or without the firewall. Then my PC begins exchanging ESP messages with the remote VPN, but only when the firewall is disabled.
It’s not clear whether these messages are being blocked, or if they are simply not being sent because of a failure in the handshaking that precedes them. But the fact that I get (or at least, used to get) all of those ESP blocked messages makes me believe that the former is true.
Since these are blocked:
PC → VPN ISAKMP Aggressive
VPN → PC ISAKMP Aggressive
Have you tried to use “main mode” instead of “aggressive mode”?
I don’t know much about this, but at least i’m bumping your thread… hehe…
Anyone else with some knowledge is welcome to help out here.
Edit: I forgot to say that when you get it to work you are welcome to post your rules and settings in the faq section for CFP 3 so other can benefit from it. We are also setting up a wiki and we are writing 3 books for users how to use/set up CFP 3.
There is also a possibility that there is a bug/problem with CFP 3 since it’s fairly new, so maybe the best option is to report it as a bug and wait for a fix before spending to much time with this issue?
I read through your posts a bit quick so I can have missed it, but have you tried to go to firewall/advanced/attack detection settings/miscellaneous and uncheck the “do protocol analysis”?
You can then also try to increase the flood rate from 20 to lets say 200 packets/second on all of them in “intrusion detection” tab.
You should try things even if they’re not logical…
I’ve tried plenty of things that make no sense – and mostly I’ve done it without objection. Once we make it work, there’s plenty of time for figuring out the logic behind it later. But I hadn’t tried either of those things. Till now.
Nope. Still no luck.
I increased all flood rates and disabled all the miscellaneous attack detections. Then, just to be sure, I rebooted. The VPN client still dies at the same place…
Still, you get 20 points for coming up with something truly new to try.
Hmmm… ok…
Another moderator and myself now have asked Comodo about this and if there will be a fix for this in the upcoming update. I think it’s a bug of some sort…
I will let you know when I get an answer.
Bless you, and thank you both. Since I have an emergency work-around, I don’t have to change firewalls – so if any questions come up I’ll be able to run tests for them.
BTW – I am also running Cicso VPN 4.8.00.0440; it works just great with CPF 3. So it’s something about Contivity software – or at least this release of it.
I’ve been able to duplicate the problem with a pair of machines here, and have found what looks like a bug. If you can check something, it might give a little more insight as to what the problem is. You may have to disable the firewall, or run in training mode.
When you try to make a connection, CFP seems to dynamically create new rules in Global Rules to allow the VPN traffic. If you look at those new rules, the destination is defined as a zone, but there is no value present. So network traffic stops. At least that seems to be what is happening in the testing that I did. If you’re encountering the same thing, or something similar, then I’d take that as an indicator that you’re tripping over a CFP bug. If your rules seem normal, then I’ll ask that you check the CFP created zone definition for the VPN connection.
Post back with what you see in the Global Rules, and the CFP created VPN zone definitions.
I just did a real fast read of the Cisco VPN 4.6 user guide on the Cisco web site. It looks like this is a very different kind of VPN. More along the lines of an SSH tunnel, using only TCP and UDP protocols like a normal application program, with “routing” happening at the endpoint application, rather than being done by the OS TCP/IP stack.
Or, phrasing it a little differently, there no network adapter as such, just a really different kind of web browser.
And with no network adapter, CFP doesn’t pay any attention to the traffic for dynamic rules, and so works just fine.
Thanks for the explanation! It’s always useful to understand what’s going on “under the hood.” I appreciate your taking the time, both to look this up and to relay the info back to me.
When I first connected to the VPN with the Firewall disabled (awhile ago now), it added a network zone with that IP and mask, which I made sure were correct. At some point I believe I added global rules to allow incoming and outgoing from/to that zone. I also have the two global rules suggested for a workaround in the previous post, set for System.
If I’m looking at Global Rules under Network Security Policy, and I start the VPN connection with the Firewall either in Custom mode or in Disabled mode, I don’t see any changes (ie dynamically applied rules) on the Global Rules page. If I look at my Network Zones while logging into the VPN, I also don’t see any changes, which I would expect, since the VPN IP address / mask is already defined as a zone.
I’m surprised this hasn’t been tracked down already by Comodo looking through the changes introduced between RC1 and the final release (per comments by zombie posted previously). If it worked in RC1 it seems like there shouldn’t be too many changes to look at which might have possibly introduced the problem.
Fascinating. I didn’t think you could add rules to System Idle Process. It was one of the first things that occurred to me to try, but I couldn’t figure out how to add rules to “nothing.”
In the last few days, though, I’ve learned a lot about CPF – so having read that it was possible I suddenly knew exactly how to do it. I just added a Network Security policy and picked “System Idle Process” out of the Running Processes dialog box.
The VPN still didn’t connect – though I’m writing from an airport and I don’t know if the VPN would normally work from here. (I’m certainly not going to turn off my firewall here in order to test it.) So I’ll check it again this evening, with Wireshark if necessary.
There is progress though; the log shows System Idle Processes successfully sending ESP packets. (I have no idea why the log is working again; as far as I know I didn’t change anything. Maybe it has to do with the fact that I’m on a foriegn network. I trusted so much the last time I set up the firewall that maybe CPF figures that there was no need to log anything from my home network.)
Thanks for the tip – it may be just what I needed. (Hmmm – where is that “fingers crossed” smiley?)
I am now connected to the Nortel Contivity VPN, and it seems to be working great. I’ll play with it for a bit to make sure it’s not going to time out in a few minutes. And (most likely tonight) I will uninstall CPF and start over again; I’m not convinced I will remember everything that I tweaked en route to this success.
The secret, for those coming in late, is that you can assign rules to the System Idle Process. It’s probably a bug that you have to do this, and it might conceivably be a security risk (since non-trusted applications might be able to hijack this facility). But I don’t think that there’s much I have to worry about – especially since it will be limited to specific IP addresses.
I’m betting that this is the only thing that needed to be done to get my firewall running – but I will write a wrap-up message when I know for sure.
Thanks again to everyone for your patience and assistance.
In conjunction with previously defined steps, that works. I did vary the last rule slightly by only making my single VPN IP Address the destination instead of using any.
hehe…