Checkpoint Lab - 10 (Building VPN tunnel) Tutorial

VPN Tunnel -  

In this section lets see how to setup an IPSec VPN tunnel between Main Office and Branch Office. In order to setup a VPN connection between 2 systems we must cover the process and methods on what happens when VPN connections is established and how it works. The main purpose of establishing a VPN tunnel is to give users access to the resources @ either offices with out creating NAT's. (Its not always possible to create NAT's for example lets say a network admin who has access to all the server and workstations travels to branch office and then is called to work on an issue in main office, its not possible to put all the servers or work stations on NAT for him to access externally. So to make sure he has access to all resources same like when he is sitting in the main office Site to site VPN can be established). Once the user VPN's in or a VPN tunnel is established they can access 10.1.1.0 or 10.2.2.0 networks including the DMZ's as soon as the policies are created.
To use any VPN technology the data packet between the 2 points need to be encrypted (DES, 3DES or AES) and the integrity of the data packet should be checked constantly (MD5, SHA) to determine the packet sent is actually the packet received.

Concept - Symmetrical key exchange

• The technology by which 2 devices use the same key to encrypt and decrypt the data packet. Content to generate and exchange must be done in secure fashion.
• Internet key exchange (IKE) is used to accomplish the above. (Version1, Version 2)
• Diffie-Hellman (DH) is the method that the symmetrical keys are built and exchanged.

There is a great article from checkpoint regarding the IPSec VPN. I would strongly recommend to read this before proceeding further.

IKE version1 - The VPN connection is setup in 2 phases.

Phase1 - Both the peers negotiate on the technologies they will use to set the connection, similar to SSL (article posted here)
They authenticate with each other using a pre shared key or a certificate.
Both the parties create a shared key that only either of them knows using DH.Using this key the subsequent data is exchanged.
At this point IKE Phase 1 tunnel is established between 2 end points.
This phase supports 2 modes
Main mode  - Its the default mode where the IKE negotiation happens using 6 packets. This mode is less vulnerable to Dos attacks. DH computations is done after the auth is done unlike aggressive mode where both are done at same time.
Aggressive mode  - It performs the IKE negotiation with three packets. (Config vai check box 13 images down - Advanced VPN Properties)

Phase2 - This kicks in when the client actually initiates the traffic. Like admin tries to connect to a server in main office.
Both the parties start a new negotiation based on the previous Phase1 negotiation (The encryption and hash values can be changed, need not be the same, we can use SHA and AES in phase2 if in phase1 we used MD5 and 3DES)
Symmetric IPSec keys are created using DH keys from phase1 and an IPSec tunnel is built for the bulk data exchange. Depending on the values selected it can be taxing on systems but hard to break and vice versa.

Checkpoint terminology for VPN

Mesh - When the requirement is to set up vpn tunnels between all the gateways so that they can talk to each other then its called Mesh topology.

Start or Hub and Spoke - When the requirement is setup a tunnel between One (Main Office) and multiple branches. The branch office can only communicate with the main office but not with each other.

VPN Community - The entire topology gateways, servers, routers, switches between which the tunnel is setup is called VPN community.
VPN Member - The gateway/Firewall from which the VPN connection will be configured is called VPN member.
VPN Domain - The network (excluding the gateway) is called VPN domain. For example 10.1.1.0 with server, DMZ, work stations, manager is called a VPN domain.
VPN Site  - VPN Domain + VPN Member.

 Now lets setup VPN tunnel between main and branch office in the lab environment.
First thing to check and enable is the IPSec VPN blade on the gateways.

Next step is to define VPN domain. A gateway has multiple interfaces, we have an option of defining which subnet should be part of the VPN domain. Go to "Topology" option  and for the VPN domain either choose all the interfaces or we can manually specify the interface which should be part of the domain. In the lab I am using the 10.X.X.X subnet so selected "Main_Internal_10.1.1.0" at main office and "Branch_Internal_10.2.2.0" at branch office.

Now a VPN community needs to be defined. So go to Smart Dash Board and select "IPSec VPN" tab.

We will setup Star or Hub and spoke community between the 2 lab gateways.

Because its hub and spoke select Main office gateway device as Center Gateways and Branch office device as Satellite Gateways by using "Add" button.

In the encryption options we can select what version of IKE to use, version 1 is selected by default (Usually version 2 is used with IPv6 and when you need to set up the site to site vpn tunnel with a non checkpoint device like Cisco or sonic wall version 2 is not supported).

Encryption Suite lets you define hash, encryption, DH algorithms...by default "Custom" is selected. As mentioned earlier the encryption can be different for phase1 and phase2 so I changed the phased 2 to AES-128 and SHA 256.

Tunnel management option lets you define how many VPN tunnels need to be opened between gateways - default value is "One VPN tunnel per subnet pair" so it uses one phase2 IPSec tunnel and let the whole subnet 10.1.1.0 and 10.2.2.0 talk.

Most important thing is to disable natting when you VPN in from one site to another because its not needed and if the user from site A connects to a resource in site B the source packet will be natted to the gateway and the resource will send the packet to the gateway.

We can also specify the DH properties at phase1 and 2, renegotiate SA option (the more number of times that its negotiated and recreated the more secure, but overhead on resources is also more)

By following the above steps the new VPN community is setup.
Next thing to accomplish is to set up the policy for the flow of traffic.  The VPN policy that need to be in place for the VPN communication to happen is below (Save and install the policy once created.)

 This completes the site to site VPN set up. So test this from main office network ping ClientB at branch office. For some reason if the ping does not work check to see the smart view tracker. If the policies are setup as per the lab example you should get a response back. Open the smart view tracker to look at the VPN traffic.

 The first key is phase1 and the second is pahse2. Double click the first key and you will see that its AES-256+SHA1 encryption as per Custom Encryption Suite (6 screenshots up)

Open the second key and you will see phase 2 tunnel build log.

Since we enabled Perfect Forward Secrecy (6 screen prints above) PFS, AES-128 and SHA 256 are displayed in the phase 2 negotiation. From the CLI perspective "vpn tu" can be used to look at the LKE and IPSec SA's. Go through all the options, try deleting the SA and initiate the ping requests and see how the communication happens.

This concludes the site to site VPN setup.