VPN-1 Pro Interoperability VPN Group January 2005 0
Abstract This document describes various aspects related to interoperability between VPN-1 Pro Gateways and the VPN solutions of other vendors. The purpose of this document is to provide information on how to setup VPN with other vendors, along with necessary workarounds. Content Content... 1 1. IKE... 2 1.1 Phase 2 IDs... 2 1.2 Phase 1 IDs... 4 1.3 Protocol and Port support in IKE phase 2... 4 1.4 Enforcing IKE Phase 2 configuration... 5 1.5 KBytes expiration support... 5 1.6 AES-128 support for IKE phase 1... 6 1.7 Overcoming install policy... 6 1.8 PKI - alternate name for certificate creation... 7 1.9 PKI - alternate name versus IP... 7 1.10 Crash recovery... 8 1.11 IPs used for VPN tunnel establishment... 9 1.12 Lifetime configurations...10 1.13 Dead peer detection (DPD)...10 2. IPSec...11 2.1 Cluster LS support...11 2.2 Configuring Phase 2 IKE properties per service...11 2.3 AH support...12 3. Routing...12 3.1GRE Tunneling...12 4. Other...12 4.1 3rd party dynamic IP GW (DAIP)...12 4.2 L2TP client support...13 Check Point Software Technologies Ltd. 1
1. IKE 1.1 Phase 2 IDs During IKE Quick Mode negotiation, the IP addresses which the VPN tunnel will hold, are negotiated. The IP addresses can be a set of single IP addresses or a subnet. This is defined by Quick Mode IDs. When negotiating a VPN tunnel between VPN-1 Pro and certain third party devices, IKE Quick Mode may fail if the subnets are defined differently. This can be easily resolved by applying one of the following: In all NG versions, the VPN-1 Pro Gateway will automatically unify adjacent subnets, resulting in the largest possible subnet, for negotiation purposes. To counter unification, use dbedit on the Gateway object, and turn off the ike_use_largest_possible_subnets flag. In versions R55 and earlier, in SmartDashboard, on the Gateway object select VPN>VPN Advanced. On this screen the field Support key exchange for subnets is checked by default. If checked, the tunnel negotiated will be valid for the entire subnet; otherwise, the tunnel will be valid per pair of hosts. Starting from NGX R60, in SmartDashboard, the subnet support can be configured either on the Gateway object or on the community object (in which case it will apply for all the Gateway members of the community, unless the Gateway was configured specifically). In addition, further configuration granularity has been added. On the Community object, Check Point Software Technologies Ltd. 2
select Tunnel Management> VPN Tunnel Sharing> Control the number of VPN tunnels opened between peer Gateways. In other words, you should choose the level of granularity you wish to apply for the tunnel being negotiated by the said Gateway. The choices are between: tunnel per pair of hosts tunnel per subnet pair, as defined in the encryption domain of the Gateways, and one tunnel per pair of Gateways. On the Gateway object itself, under VPN>VPN Advanced>VPN Tunnel Sharing, specify whether you would like to use the setting configured on the community of which this Gateway is a member (the default setting,) or whether you would like to apply a specific configuration for this Gateway. If a Gateway is a member of more than one community, the configuration on the community which defines the tunnel being negotiated, will be the deciding settings. In this manner, it is possible to configure the level of granularity to match the one used by the third party vendor. It is possible to configure a subnet to be used per range of IP addresses. Meaning, when negotiating a tunnel for a certain IP address, the subnet for which the newly negotiated tunnel will be valid, will be set according to this configuration. In this manner, one can configure various subnets to be used for different segments of the VPN domain. This feature has been available since NG with Application Intelligence, version R55. Check Point Software Technologies Ltd. 3
If the granularity described above is still insufficient, it is possible to configure a subnet to be used per peer Gateway. In this manner, you can apply a specific configuration to a third party peer. This feature is available from NGX R60. 1.2 Phase 1 IDs IKE phase 1 negotiation contains an ID payload. The ID payload may contain the IP addresses of the Gateways participating in the IKE negotiation. In this case, VPN-1 Pro uses the main IP address of the Gateways for this purpose (this is defined in the General Properties tab of the Gateway object in SmartDashboard). However, the IP address that is sent in the ID payload is not necessarily the IP address that will be used for the IKE negotiation and for the VPN tunnel. This inconsistency may cause connectivity failure when opening a VPN tunnel between VPN-1 Pro and third party devices. In NGX R60, in SmartDashboard on the Gateway object, select VPN>Link Selection. If a single IP is selected for incoming traffic (the default setting), then the IP address sent in the ID payload and the IP address actually used for the IKE negotiation and VPN tunnel will be the same. 1.3 Protocol and Port support in IKE phase 2 RFC 2407 (http://www.ietf.org/rfc/rfc2407.txt) section 4.6.2 includes the protocol and port as part of the system Security Policy requirement for the association. This information is negotiated as part of the ID payload in IKE Quick Mode. VPN-1 Pro will successfully complete a Quick Mode negotiation including this Check Point Software Technologies Ltd. 4
information; however, will not enforce the negotiated port and protocol. A workaround for this would be to configure the third party device so that it does not negotiate the port and protocol as part of phase 2 negotiation. 1.4 Enforcing IKE Phase 2 configuration When working in Traditional Mode, the IKE Phase 2 properties are configured in the SmartDashboard Rule Base, (select Action>Encrypt> Encryption Properties tab). This configuration defines the properties of the specific tunnel. When initiating a connection, these properties will be used for establishing a VPN tunnel. However, when responding to an IKE negotiation, these tunnel properties are not enforced during the IKE negotiation, but rather when receiving the first packet of the connection. During the IKE negotiation itself, a VPN-1 Pro Gateway will agree to anything it is configured to support. Moreover, VPN-1 Pro will choose to work with the strongest proposed methods that it supports, rather than the methods configured on the encryption rule and on the basis of this choice, it will fail the connection for reason of misconfiguration of the tunnel. This can be resolved by working in Simplified mode. In this mode, all the methods are configured on the community, and the supported methods and the methods that are enforced are one and the same. 1.5 KBytes expiration support Using Simplified mode, IKE rekeying based on Kbytes cannot be configured. However, when a VPN-1 Pro Gateway with a Simplified policy is offered to use Kbytes, the proposal will be accepted. Check Point Software Technologies Ltd. 5
1.6 AES-128 support for IKE phase 1 By default, AES-128 for IKE phase 1 cannot be configured using SmartDashboard. Starting from R54, in order to enable AES-128 for IKE Phase 1, use dbedit, and set the Global Property 'ike_support_aes_128_p1' to true. Once this is done, in SmartDashboard, the AES-128 option will be available for IKE phase 1 configuration, both on the community object and the Gateway object. From NGX R60, support for AES-128 for IKE phase 1 is available by default and there is no need to modify dbedit configurations. 1.7 Overcoming install policy When installing a policy on a VPN-1 Pro Gateway, all IKE SAs will be deleted, with the exception of SAs used for Remote Access connections. The exception is on account of security reasons. In case the security configuration has been changed in the newly installed policy, the IKE properties should be renegotiated. In case a remote Gateway tries to use an SA that has already been deleted, a Delete Notification will be sent and IKE will be renegotiated. This will result in a newly established VPN tunnel. However, there are some Vendors, Cisco in particular, which don t support Delete Notifications. As a result, after policy installation, connectivity between a VPN-1 Pro Gateway and a third party Gateway may break. A proposed work around is to check keep_ike_sas in SmartDashboard, under Global Properties> SmartDashboard Customization>Advanced Configuration>Configure>VPN Advanced Check Point Software Technologies Ltd. 6
Properties>VPN IKE properties. When checked, IKE SAs will not be deleted when the policy is installed. 1.8 PKI - alternate name for certificate creation Many Vendors require that a certificate received by the peer GW will contain an alternate name extension with either IP address or DNS. When using the SmartDashboard to configure a certificate it is not possible to configure an alternate name as part of the request for a certificate from the Internal CA. In NGX R60 a new option will allow you to specify in the request for a certificate that an alternate name field be included, both for OPSEC and Internal CAs. In order to have this option configured automatically (with the main IP address), in SmartDashboard, check add_ip_alt_name_for_ica_certs and add_ip_alt_name_for_opsec_certs under Global Properties> SmartDashboard Customization> Advanced Configuration> Configure>Certificates and PKI properties. 1.9 PKI - alternate name versus IP There are third party devices that during IKE negotiation compare the IP address included in the certificate (under the alternate name extension) with the one from which the IKE packet has been received. In the event that they don t match, the IKE negotiation may fail. To avoid this issue, make sure that the IP address that is configured to be used during IKE negotiation and the IP address that is configured to be included in the alternate name field of the Check Point Software Technologies Ltd. 7
certificate are the same. See section 1.11 for further information on how this can be configured. 1.10 Crash recovery Upon restart VPN-1 Pro looses all IKE and IPSec SAs previously negotiated with other peers. When receiving an IKE or IPSec packet encrypted with an SA that is no longer available, the VPN-1 Pro Gateway will send a Delete Notification in order to inform the peer Gateway that this SA should no longer be used. There are, however, Vendors that don t support IKE Delete Payloads, Cisco in particular. In such cases VPN connections with these third party devices may not recover if the Check Point Gateway is restarted, until the latest negotiated SA expires. In order to allow connection recovery in such cases, Initial Contact Mechanism is now supported. Support of Initial Contact as receiver is available by default from version NG FP1. This can be configured by modifying ike_handle_initial_contact in SmartDashboard, under Global Properties>SmartDahboard Customization> Advanced Configuration>Configure>VPN Advanced Properties>VPN IKE properties. Support of Initial Contact as initiator is available from version NG FP3. In order to activate it, set the global attribute ike_send_initial_contact to true using dbedit. The default value is false. Check Point Software Technologies Ltd. 8
From NGX R60, instead of using dbedit, you can also make this modification in SmartDashboard by selecting Global Properties>SmartDashboard Customization> Advanced Configuration>Configure>VPN Advanced Properties>VPN IKE properties. Note that SecuRemote/SecureClient doesn t send initial-contact message. In addition, a VPN-1 Pro Gateway will not send an initial-contact message if the peer is mobile or a DAIP Gateway. 1.11 IPs used for VPN tunnel establishment VPN-1 Pro is tolerant to a change of IP addresses during IKE negotiation. In particular, it is tolerant to cases where an IKE packet is sent to one IP address while the return packet is sent from another IP address; other Vendors may fail the negotiation for this reason. In R55 and earlier versions: using dbedit, make sure that the global property IPSec_orig_if_NAT is turned on, (the default value is true ). When turned on, all IKE and RDP return packets will use the same IP address that was used on the received packet. In NGX R60, in SmartDashboard, on the Gateway object select VPN>Link Selection>Outgoing Route Selection>Advanced Settings. You can select the IP address to use as responder to IKE and RDP packets. In other words, the IP address is the source IP of the responding packets. In order for this to apply on IPSec packets as well, make sure the correct IP address, that is, the IP address used by the third party device to address Check Point Software Technologies Ltd. 9
the VPN-1 Pro Gateway, is configured under the IPSec selection by Remote Peer. By default this IP address will also be used as source IP for outgoing IPSec packets. 1.12 Lifetime configurations In cases where there s a misconfiguration between a VPN-1 Pro and 3 rd party VPN Gateway in terms of SA expiry times, connectivity failures may occur. VPN-1 Pro Gateways overcome misconfigurations of this kind by using Delete Notifications and Responder Lifetime Notifications. However, these notifications are not supported by some of the 3 rd party vendors, Cisco in particular. In order to avoid these misconfigurations make sure the expiration timeout is defined similarly on both sides. This can be configured as follows: In Traditional mode: In SmartDashboard, on the Gateway object select VPN>Traditional mode configuration>advanced>rekeying Parameters In Simplified mode: In SmartDashboard, on the community object select Advanced Settings>Advanced VPN Properties, under IKE (phase 1) or IPSec (phase 2). 1.13 Dead peer detection (DPD) The VPN-1 Pro Gateway does not support the standard Dead peer detection draft. When configuring third party devices to open a VPN tunnel with a VPN-1 Pro Gateway, make sure that dead peer detection is not activated. Check Point Software Technologies Ltd. 10
2. IPSec 2.1 Cluster LS support Using VPN-1 Pro on a cluster solution, Load Sharing is implemented by maintaining an IPSec SA per cluster member. Since the cluster members are configured as one entity (a cluster), there are some third party devices that cannot accept more than one SA for a given peer. Specifically, this applies to Cisco Gateways, L2TP clients and Nokia clients. There are several ways to work around this: In NGX R60, ClusterXL supports the sticky decision function: meaning that a given peer will stick to one cluster member only and will be aware of one IPSec SA per Cluster. If working with an earlier version of ClusterXL and a 3 rd party VPN device, use Cluster High Availability (HA) rather than Cluster Loadsharing (LS). In the HA implementation, only one IPSec SA is maintained for the cluster per peer Gateway, (the information is synched between the cluster members). 2.2 Configuring Phase 2 IKE properties per service In Traditional Mode, IKE Phase 2 properties were configured on the encryption rule. Therefore, incidentally, it was possible to configure a different configuration for different services. However in Simplified Mode all IKE properties related to a community are configured on the community object. As a result, when working with Simplified mode, phase 2 configuration per service is no longer available. Check Point Software Technologies Ltd. 11
2.3 AH support Since NG FP2, AH is no longer supported. When a VPN-1 Pro Gateway is prompted to use AH during the IKE negotiation, a No proposal chosen Notification will be sent to the peer and an informative log will be displayed in SmartView Tracker. 3. Routing 3.1GRE Tunneling Some of the 3rd party solutions, including Cisco, support dynamic routing over VPN only by GRE over VPN. Starting from NGX R60, this is supported by the VPN-1 Pro Gateway. Enable GRE in SmartDashboard as follows: On the Gateway object of the Interoperable device, under VPN>VPN Advanced>VPN Tunnel Sharing, check Custom settings, instead of the default Use the community settings. Select One VPN tunnel per Gateway pair and choose GRE on IPSec from the drop down list. This means that any Gateway working with this Interoperable Gateway will add the extra GRE encapsulation required to work with this Gateway. 4. Other 4.1 3rd party dynamic IP GW (DAIP) In NGX R60 there is support for VPN between VPN-1 Pro Gateway and a 3 rd party DAIP Gateway. This is not supported in earlier versions. Check Point Software Technologies Ltd. 12
In order to enable VPN connections between a VPN-1 Pro Gateway and a Netscreen DAIP Gateway, in dbedit, turn on the global property ike_allow_unusual_id_types. 4.2 L2TP client support VPN-1 Pro Gateway supports Win2k and windows XP L2TP clients. The L2TP client does not receive topology from the Gateway. Therefore it will route all traffic through the Gateway. Since this was not supported in early versions, packets that were not destined to the encryption domain were dropped by the VPN-1 Pro Gateway. o In NGX R60 this will be supported, meaning, packets to the Internet will be routed through the VPN-1 Pro Gateway. Authentication methods used by L2TP clients: o EAP including MD5-Challenge and TLS. These are supported by VPN-1 Pro Gateway since NG FP3 and can be used for certificate authentication. In addition, there are other EAP methods which can be installed on the client. However, these methods are not supported by VPN-1 Pro Gateway. o PAP protocol is supported in NGX R60. It can be used for all userpassword type authentication, such as RADIUS, SecureID, etc. o SPAP, CHAP, MS-CHAP, MS-CHAPv2 are not supported by VPN- 1 Pro Gateway. NAT-T support: in NGX R60 there is support for NAT-T with L2TP clients. Check Point Software Technologies Ltd. 13
Check Point Software Technologies Ltd. 14