Home Page | Skip to Navigation | Skip to Content | Skip to Search | Skip to Footer

Developer Resources

Gateway/Management Integration

Communication Modes
The OPSEC infrastructure provides a host of choices to secure the communication between the application and VPN-1/FireWall-1. This section discusses the different modes of communication and the configuration process.

Using the Check Point SIC infrastructure, OPSEC applications can establish one of the following types of connection with VPN-1/FireWall-1:

Authenticated The OPSEC application and VPN-1/FireWall-1 verify each other's identities before data is exchanged.
Authenticated and Encrypted The OPSEC application and VPN-1/FireWall-1 authenticate to each other and the information exchanged is encrypted using a 3DES or RC4 key.
Clear Communication The OPSEC application and VPN-1/FireWall-1 exchange information without authentication and/or encryption. This method should be used for testing and debugging only. It is not recommended to deploy this in the real world because the APIs can potentially expose information about the network structure and could be construed as a security risk.

The OPSEC SDK 4.1.2 provides four modes of communication between the OPSEC application and VPN-1/FireWall-1.

  1. clear - No authentication/encryption
  2. auth_opsec - Check Point proprietary authentication
  3. ssl_clear_opsec - Authentication via an SSL tunnel
  4. ssl_opsec - Authenticated and Encrypted tunnel

The default modes of communication and ports for VPN-1/FireWall-1 4.1.SPx are

CVP
18181
auth_opsec
UFP
18182
auth_opsec
SAM
18183
auth_opsec
LEA
18184
auth_opsec
ELA
18187
ssl_opsec
UAA
19191
ssl_opsec

The default modes of communication and ports for VPN-1/FireWall-1 NG are:

CVP
18181
sslca_clear
UFP
18182
sslca_clear
SAM
18183
sslca
LEA
18184
sslca
ELA
18187
sslca
CPMI
18190
sslca
AMON
18193
sslca
UAA
19191
sslca

OPSEC SDK NG introduced new certificate based authentication and encryption methods in addition to the previous methods. OPSEC applications compiled with OPSEC SDK NG must support the new syntax of the SIC infrastructure. The OPSEC application and the Check Point module exchange version information. If there is a version difference, the OPSEC infrastructure will work in backwards compatibility mode. If they are the same version, (NG and forwards) they will not accommodate the older syntax.

VPN-1/FireWall-1 NG will work seamlessly with OPSEC applications using SDK 4.1.2 if default communication mode and the default port have not been changed. OPSEC Applications using SDK 4.1.2 cannot take advantage of the new features of NG like certificate-based authentication and encryption.

Steps to implement authentication and/or encryption

The OPSEC application and the corresponding VPN-1/FireWall-1 should be configured for the same communication method. The communication method on VPN-1/FireWall-1 is configured using the file $FWDIR/conf/fwopsec.conf. The communication method on the application can be configured via a user interface or a configuration file according to the partner's preference. It is however required to provide an easy way to configure the other modes.

  1. Configure both VPN-1/FireWall-1 and the OPSEC application to use the same communication method.
  2. If the OPSEC application and VPN-1/FireWall-1 use Check Point's proprietary authentication algorithm (fwn1 and auth_opsec) or SSL based authentication (ssl, ssl_opsec, ssl_clear_opsec), create authentication key (using fw putkey) on the VPN-1/FireWall-1 machine. If they are to use certificates (sslca, sslca_comp, sslca_rc4. sslca_rc4_comp, asym_sslca, asym_sslca_comp, asym_sslca_rc4, asym_sslca_rc4_comp, sslca_clear), create a certificate for the OPSEC application on the management server, which is also an Internal Certificate Authority.
  3. Create the authentication key (using opsec_putkey) on the OPSEC application machine or retrieve the certificate in PKCS#12 format (using opsec_pullcert) from the management server.

OPSEC Applications are forwards and backwards compatible. This means that applications compiled with OPSEC SDK 4.1.2 can communicate with VPN-1/FireWall-1 NG and applications compiled with OPSEC SDK NG can interoperate with VPN-1/FireWall-1 4.1.SPx.

New communication methods introduced in OPSEC SDK NG are not backwards compatible.

The next few sections describe configuring the OPSEC application to communication with VPN-1/FireWall-1, taking into consideration version differences:

VPN-1/FireWall-1 4.1 with OPSEC Application using SDK 4.1.2
VPN-1/FireWall-1 NG with OPSEC Application using SDK 4.1.2
VPN-1/FireWall-1 NG with OPSEC Application using SDK NG

VPN-1/FireWall-1 4.1 with OPSEC Application using SDK 4.1.2
Use default port and communication mode

If a LEA application wants to communicate with the VPN-1/FireWall-1 LEA server to get log information using the default port and the default mode of communication, the following steps are needed.

On the VPN-1/FireWall-1 machine

  • Stop VPN-1/FireWall-1 by executing fwstop
  • fw putkey -opsec <lea_application_ip_address>
  • Start VPN-1/FireWall-1 by executing fwstart

On the LEA Application machine

  • Specify the LEA server configuration in the application's configuration. This will typically consist of three lines relevant to OPSEC

    lea_server  ip_address  x.x.x.x
    lea_server  auth_port   18184
    lea_server  auth_type   auth_opsec

  • opsec_putkey . This will create a file called "authkeys.C" which will be used for authentication. Please make sure this file is accessible to the LEA application. The OPSEC infrastructure will look for this file in the directory that the environment variable "OPSECDIR" specifies. If OPSECDIR is not set or the file is not available in the directory, it will look for the file in the current working directory. If the "authkeys.C" file cannot be accessed, the authentication will fail and the communication between the OPSEC application and VPN-1/FireWall-1 will not be initialized.
  • Start the LEA application.

VPN-1/FireWall-1 4.1 with OPSEC Application using SDK 4.1.2
Change communication mode to ssl_opsec on default port

If a LEA application wants to use ssl_opsec, the following steps are needed.

On the VPN-1/FireWall-1 machine

  • Stop VPN-1/FireWall-1 by executing fwstop.
  • Edit $FWDIR/conf/fwopsec.conf and change the line "lea_server auth_type auth_opsec" to "lea_server auth_type ssl_opsec". Do not change the line "lea_server auth_port 18184"
  • fw putkey -opsec -ssl <lea_application_ip_address>. Be sure to use the "-ssl" option.
  • Start VPN-1/FireWall-1 by executing fwstart

On the LEA Application machine

  • Specify the LEA server configuration in the application's configuration. This will typically consist of three lines relevant to OPSEC

    lea_server  ip_address  x.x.x.x
    lea_server  auth_port   18184
    lea_server  auth_type   ssl_opsec

  • Use the "-ssl" option with opsec_putkey also. The command will be opsec_putkey -ssl <vpn-1-fw-1_ip_address>. This will create a file called "sslkeys.C". The same rules as "authkeys.C" apply to this file
  • Start the LEA application

The steps to use ssl_clear_opsec are same as above. Replace "ssl_clear_opsec" for "ssl_opsec".

VPN-1/FireWall-1 4.1 with OPSEC Application using SDK 4.1.2
Change communication mode to clear

If a LEA application wants to use no authentication or encryption to communicate with VPN-1/FireWall-1, the following steps are needed. This mode should be used for debugging purposes only since the data passed between the application and VPN-1/FireWall-1 might contain sensitive information. On the VPN-1/FireWall-1 machine

  • Stop VPN-1/FireWall-1 by executing fwstop
  • Edit $FWDIR/conf/fwopsec.conf. Change the line "lea_server auth_port 18184" to "lea_server port 18184"
  • Comment out the line "lea_server auth_type auth_opsec" by placing a # at the beginning of the line "#lea_server auth_type auth_opsec"
  • Start VPN-1/FireWall-1 by executing fwstart

On the LEA Application machine

  • Specify the LEA server configuration in the application's configuration. This will typically consist of two lines relevant to OPSEC

    lea_server  ip_address  x.x.x.x
    lea_server  port        18184

  • Start the LEA application

VPN-1/FireWall-1 4.1 with OPSEC Application using SDK 4.1.2
Change the default port number

If a LEA application wants to use a port other than 18184 to communicate with VPN-1/FireWall-1, the following steps are needed.

On the VPN-1/FireWall-1 machine

  • Stop VPN-1/FireWall-1 by executing fwstop
  • Edit $FWDIR/conf/fwopsec.conf. Change the line "lea_server auth_port 18184" to "lea_server auth_port 19199"
  • Start VPN-1/FireWall-1 by executing fwstart

On the LEA Application machine

  • Specify the LEA server configuration in the application's configuration. This will typically consist of two lines relevant to OPSEC

    lea_server ip_address x.x.x.x
    lea_server auth_port 19199

    The port number specified here should be the same as specified in $FWDIR/conf/fwopsec.conf

  • Start the LEA application

VPN-1/FireWall-1 NG with OPSEC Application using SDK 4.1.2
Use default port and communication mode

If a LEA application compiled with SDK 4.1.2 is using the default communication mode (auth_opsec) and the default port (18184), the following steps are needed to setup the communication with VPN-1/FireWall-1 NG.

On the VPN-1/FireWall-1 machine

  • Stop VPN-1/FireWall-1 by executing cpstop
  • fw putkey -opsec <lea_application_ip_address>
  • Start VPN-1/FireWall-1 by executing cpstart

On the LEA Application machine

  • Specify the LEA server configuration in the application's configuration. This will typically consist of three lines relevant to OPSEC

    • lea_server ip_address x.x.x.x
    lea_server auth_port 18184
    lea_server auth_type auth_opsec

  • opsec_putkey <vpn-1-fw-1_ip_address>
  • Start the LEA application

VPN-1/FireWall-1 NG with OPSEC Application using SDK 4.1.2
Change the communication mode to ssl_opsec on the default port

If a LEA application wants to use ssl_opsec, the following steps are needed. On the VPN-1/FireWall-1 machine

  • Stop VPN-1/FireWall-1 by executing cpstop
  • Edit $FWDIR/conf/fwopsec.conf and change the line "lea_server auth_type auth_opsec" to "lea_server auth_type ssl_opsec". Do not change the line "lea_server auth_port 18184"
  • fw putkey -opsec -ssl <lea_application_ip_address>. Be sure to use the "-ssl" option.
  • Start VPN-1/FireWall-1 by executing fwstart

On the LEA Application machine

  • Specify the LEA server configuration in the application's configuration. This will typically consist of three lines relevant to OPSEC

    lea_server ip_address x.x.x.x
    lea_server auth_port 18184
    lea_server auth_type ssl_opsec

  • Use the "-ssl" option with opsec_putkey also. The command will be opsec_putkey -ssl <vpn-1-fw-1_ip_address>. This will create a file called "sslkeys.C". The same rules as "authkeys.C" apply to this file
  • Start the LEA application

The steps to use ssl_clear_opsec are same as above. Replace "ssl_clear_opsec" for "ssl_opsec"

VPN-1/FireWall-1 NG with OPSEC Application using SDK NG
Use default port and communication mode

If a LEA application compiled with SDK NG is using the default communication mode (sslca) and the default port (18184), the following steps are needed to setup the communication with VPN-1/FireWall-1 NG.

  • Define the OPSEC application object in the Check Point Policy Editor. At the bottom of the dialog box click on the 'Communication' button. This will generate the object's DN (distinguished name). The DN will be used in the SIC communication to identify the object. Hence it is also called the SIC name.
  • Obtain the DN of the Check Point module, the management server or the enforcement module. Double click on the object in the Policy Editor. The SIC name (is the same as the DN) is at the bottom of the dialog box under 'Secure Internal Communication', next to the 'Communication' button.
  • The certificate is also created when the OPSEC application communication is initialized

On the LEA Application machine

  • Specify the LEA server configuration in the application's configuration. The configuration file "lea.conf" in NG should look like

# ELA SIC name is created when the OPSEC application is
# defined using the policy editor. If you double-click
# on your OPSEC application object, the SIC name in at
# the bottom of the dialog box.

opsec_sic_name "CN=lea_client,O=london.mydomain.com.n87vjo"

lea_server  ip         x.x.x.x
lea_server  auth_port  18184
lea_server  auth_type  sslca

# LEA Server SIC name. In the policy editor, double-
# click on your management server object, the server
# SIC name is at the bottom of the dialog box.

lea_server  opsec_entity_sic_name  "CN=cp_mgmt,O= london.mydomain.com.n87vjo"

# Optionally the application can specify a SIC policy
# file and a name for the certificate file.
# The default name for the certificate file is
# opsec.p12.

opsec_sslca_file       "lea_client.p12"
opsec_sic_policy_file  "mysicpolicy.conf"

  • Retrieve the certificate from using 'opsec_pullcert'

    opsec_pullcert -h <vpn-1-fw-1_ip_address> -p <one-time-password> -o lea_client

  • Start the LEA application