Documente Academic
Documente Profesional
Documente Cultură
Steve Luke
Atos Origin
14th February 2003
Version Description
0.1 Draft – Steve Luke
0.2 Initial Proof Release – Steve Luke
1.0 Official Release (Added Appendix / TOC) – Steve Luke
Table of Contents..............................................................................................3
Introduction......................................................................................................4
Test Environment..............................................................................................4
Checkpoint FW-1 Configuration ..........................................................................5
Using NAT with the VPN ..................................................................................11
Nortel Contivity Configuration ..........................................................................12
Appendix A: Troubleshooting / Issues Experienced...........................................18
This document defines the configurations needed for site-to-site VPN connectivity between a
Checkpoint FW-1 firewall and a Nortel Contivity Extranet VPN switch.
Test Environment
Checkpoint
Nortel Contivity
Schematic
VPN Tunnel
LAN LAN
Test PC 1 Test PC 2
The following are screenshots and descriptions of the configuration necessary to create a VPN
tunnel between a Checkpoint FW-1 firewall and a Nortel Contivity Extranet Switch.
• CP FW Object (Naturally!!!)
• Nortel Contivity Object
• Network Object for Local Network (Encryption Domain)
• Network Object for Remote Network (Encryption Domain)
Other Settings
CP FW Object
The checkpoint object should have the external IP address as the main Interface address on
the ‘General’ tab of the object properties. It should also be licensed to this address.
Although this is not essential for some operation, it has been see in test and production
environments to cause connectivity issues for VPN’s and Client VPN’s.
The important settings for this object are the VPN tab settings:
It does not matter for this screen, if you have more than one option selected (ie. DES + CAST
+ 3DES, or MD5 + SHA1) as long as DES is selected, MD5 and Support keys…..
This object should be set as an External / Gateway on the General tab as follows:
Network Objects
You should create a network object for each of the 2 encryption domains. The size of the
local encryption domain subnet is critical, this is the network object you are going to specify
in the CP FW Object in the VPN tab. If you already use a group object with many networks in
it as your encryption domain, then the network object in that group in which the connections
will be initiated from must be correct. If this is not the same as what is specified in the
Branch Connection Static Routing setting on the Contivity, this will not work.
The remote network object should be specified as the domain in the Contivity FW Object
(VPN tab)
This is where you specify the IKE / Rekey timeouts for the connection. As noted before this
is not essential, but preferable for smooth operation.
These are the rules that specify how the Initial VPN key exchange and setup is performed
between the 2 firewalls.
Encryption Rules
These rules specify the traffic that should be encrypted and sent down the tunnel.
Right Click on ‘Encrypt’ and select ‘Edit Properties’. Here you will specify how the traffic is
encrypted.
If you need to use NAT on the Checkpoint side, so that the Nortel side does not see your
private IP addresses, the following should be done:
Conclusion
That concludes the configuration of the Checkpoint FW-1. You should now push the policy
and bounce the FW (fwstop ; fwstart)
Creation of the local network is as follows (if this is not already done)
1. Go to Profiles – Networks
2. Enter a name and click ‘Create’
3. Edit the properties as below:
4. Close
3. OK the name
4. Click ‘Edit’ next to the new Group you have created. Then configure the options as in
the picture below.
Replication
On initial build of the test systems, using a standard VPN type configuration on both firewalls,
I received the same error messages as seen in the production environment. These errors
were:
Invalid ID Information
This is caused by a subnet size mismatch in the encryption domain of the CP Firewall, and the
Branch Office Static Routing section of the Contivity. If the subnet in the domain settings of
the Checkpoint FW object is of a different size to the network specified in the Static Routing
section of the Contivity, Phase 1 of the negotiation will complete, but at Phase 2 Stage 1, the
negotiation breaks down and the Contivity returns and error to the Checkpoint FW.
11:24:50 keyinst x.x.x.x >daemon src x.x.x.x dst x.x.x.x IKE Log:
Phase 1 completion. DES/MD5/Pre shared secrets Negotiation Id:
471f77ee89fc09ef-7a469014265b7bc8
11:24:50 keyinst x.x.x.x >daemon src x.x.x.x dst x.x.x.x IKE Log:
Received Notification from Peer: invalid id information Negotiation
Id: fbded2df
The caveat here is that this problem does not show if the connection is initiated from the
Contivity (via the Test VPN option). However, even though both Phase 1 and 2 complete
successfully and the tunnel appears to be up, traffic will still not flow.
NB: This can also occur if ‘Support Key Exchange for Subnets’ is disabled on the CP FW-1.
No Proposal Chosen
12:15:30 keyinst x.x.x.x >daemon src x.x.x.x dst x.x.x.x IKE Log:
Received Notification from Peer: no proposal chosen
This mismatch can occur because the settings are different for:
For the exact settings needed to synchronise both firewalls please read the next section on
configuration.
Invalid cookie
This is a very sporadic error, that only occurred twice in production and twice in test. There
are 2 possibilities as to why this happens, a possible error with PFS, or with Rekey timeouts,
both however, are issues relating to the re-establishment of a previously established tunnel,
having changed configuration. This issue does not occur on FW-FW VPN’ s, only with FW-
Other VPN’ s. Checkpoint believe this to be a possible error with encryption domains
(https://support.checkpoint.com/advanced/idsearch.jsp?id=sk6468&QueryText=%28%22inva
lid%22+AND+%22cookie%22%29&) , however this was not the case here. It was an error
that appeared after a change to the Nortel. The two solutions I have found are to bounce
the firewall (fwstop ; fwstart) or to delete the SA’ s from the state tables. The second
solution however, only applies if the policy was pushed before the last tunnel establishment,
as a policy push clears the state table anyway, and backs it up to an ‘old state table’ which
the kernel references for previous connections.
This is not an error relating to our tests, just an error that appears with certain configuration
changes that need a firewall bounce.
Successful Operation
The highlighted text above is the name of the Branch Office Connection that was configured
on the Contivity for the CP network. This name must match the one configured.
NB: These Contivity messages do not necessarily indicate a successful connection, if the
failure is on the CP side, you can still see these messages in the log. A successful connection
is indicated by 1) both logs reporting successful, and 2) traffic being passed.
Notes
1. Many documents suggest that the IKE and Rekey timeouts should be synchronised
for this to work, however, in testing the connection worked even with different
timeouts, although this may cause intermittent issues during the connection.
2. Many documents also say that ‘Supports Aggressive Mode’ is not supported, whereas
in the test environment, it made no difference being on or off.