Leonardo, The issue you ran into in your original setup was to be expected. The "encryption domain" is (for the most part-- more on this later) how the Check Point identifies the network on "its side", from the perspective of a non-Check Point device at the other end.
In a VPN, both sides have to agree on what devices are going to be allowed to talk through the tunnel. In your original setup the Check Point (by virtue of using a Class B subnet mask) was going to negotiate to allow hosts to communicate through the tunnel that the Cisco (by virtue of using a Class C subnet mask) was not configured to let through. Consequently, Phase 2 of the VPN negotiation would be expected to fail. This is by design, and it is part of what makes IPSec-based VPNs secure (imagine the consequence if one side of the tunnel could, by adding new networks/hosts to the list, force the other to "let hosts in" that they had not authorized). Obviously this gets you to the question you have right now: handling of groups. From the Check Point perspective there are effectively two ways this can get handled. (BTW, it's been awhile since I pondered this Q, so maybe there's a more elegant way-- hopefully others will chime in). Option 1: Disable subnet support on the object corresponding to the Cisco in your CP rulebase. Issue: This means that you will wind up with one tunnel per host that wants to connect. Not a good option if your entire point is to do a network-to-network VPN. The CP will handle this pretty gracefully configurationwise, but the Cisco may not-- you may wind up typing a long list of authorized boxes. However, if you only need access between specific hosts, it may be workable in addition to being more precisely controlled. Option 2: Enable subnet support (which it sounds like you already have) on the object corresponding to the Cisco in the CP rulebase. If the tunnel is down, when a host in your encryption domain attempts to connect to something on the Cisco side, the CP will attempt to negotiate network-to-network tunnel based on the IP address of the host. In other words, if host 192.168.25.34 tries to talk to the Cisco-protected end, it will try to run Phase 2 as coming from 192.168.25.0/24. The problem here is that under option 2, the CP has to make assumptions about the proper subnet mask, and those assumptions have to agree with whatever you've told the Cisco box or Phase 2 will fail. I don't remember how the CP makes its assumptions (I think it either bases it on the proper class of the IP address, or it assumes Class C all the time-- don't know), but if those assumptions don't line up with your actual network topology you will probably be in for some troubleshooting. Also note that in the case of Option 2, the encryption domain is not necessarily going to be the same as what the CP tries to negotiate for in phase 2. Under CP version 4.1, I believe I had VPNs where I defined a single host as the encryption domain, but because subnet support was on, the CP tried to negotiate Phase 2 for that host's entire network. Surprised me, and I rolled back to Option 1 as a result. I don't know whether NG exhibits this behavior-- by the time I had figured this out I was mostly using Option 1 by default-- but I'm betting it does. In any event, there really isn't a Phase 2 equivalent host or network that corresponds to a "group" in terms of how IPSec actually works. So the expected behavior when you use these kinds of things boils down to vendor implementation, which can obviously vary. So on the CP, the group proper effectively goes unused in the actual Phase 2 negotiation; instead, the CP uses either the group member's IP address or its implied network address as described above. With this in mind you can use groups without a problem, so long as you know what to expect the CP to attempt in terms of the Phase 2 comms, and so long as you've told the Cisco end to expect the same. Hope this helps. --- Russell Washington, CCSE, CCSA, NCSA Too many doggoned letters after my name.../ ----- Original Message ----- From: "Leonardo Boulton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 03, 2003 4:14 AM Subject: [FW-1] Cisco to Check Point VPN Hi lads, I've been trying to configure a VPN between a Check Point NG (FP1 and FP3) to Cisco Concentrator 3000 VPN. Finally, I was able to establish the tunnel. I had the following problem: |-------[CP NG FP3]----Internet----[Cisco]----| Net 1 Net 2 When I ping (as in access anything at all) from Net 2 to net 1, everything is fine.... when you try to ping from net 1 to net 2 only phase 1 is completed but phase 2 isn't. The message that I get in both logs is that the Cisco is sending a "delete SA" message to the Check Point peer. After some research, I found out that this is due to the Cisco peer: both encryption domains must be set exactly alike. I mean, both Encryption domains must be configured as the same subnetwork... it is not posible for you to have a Class B encryption domain defined for the Check Point (in the Check Point object) and a class C encryption domain defined in the Cisco side (for the Check Point encryption domain). I configured the same subnet as the Check Point encryption domain in both peers, and everything worked fine. Now, I have the following question for you guys.... what if I have a group defined in the Check Point side as the encryption domian?. It is not posible to configure a group on the Cisco side... it has like a field that you can fill with a subnet and a mask (I don't know that much of the Cisco concentrator, actually, I don't know anything at all!, that's why I came to you....). Is it posible to define like a group, or a list, as an encryption domain?. What should/can I do?. Cheers, nd thanks, LB ================================================= To set vacation, Out Of Office, or away messages, send an email to [EMAIL PROTECTED] in the BODY of the email add: set fw-1-mailinglist nomail ================================================= To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================= If you have any questions on how to change your subscription options, email [EMAIL PROTECTED] ================================================= ================================================= To set vacation, Out Of Office, or away messages, send an email to [EMAIL PROTECTED] in the BODY of the email add: set fw-1-mailinglist nomail ================================================= To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================= If you have any questions on how to change your subscription options, email [EMAIL PROTECTED] =================================================
