You are on page 1of 41

Wednesday, March 2, 2016

In this nugget we built VPN tunnel between FW1 & FW2

Now lets talk about the protocols use in the VPN

Suppose Bob on the network 10.2.2.68 at branch office and want to communicate with the HQ server on
the IP 10.1.1.95 so if everything is setup and VPN is establish then what happen at the branch office FW
as the bob initiate the communication for the server ,FW2 encrypt the packets through the options we
have

1.DES

2.3DES

3.AES : which is more secure and the flavor of the symmetric encryption

Data Integrity :

As the data move up on the network we want to make sure that data will not loss in transit or corrupted or
lose any single bit of the data for that we use data integrity algorithm here we have the

1.MD5

2.SHA

These are the data integrity protocols


Authentication :

The other cool thing about the VPN tunnel is that one gateway authenticate another gateway so the other
part of the tunnel is actually who it suppose to be

So suppose we have configure the rules on the both firewalls but the communication is not started yet
then what happen first is that

IKE Phase 1 here we are using the IKEv1 not the IKEv2

IKE Phase 1 : So the FW2 says that oh I have to make communicate for the bob traffic to the server
located on the inside network of the FW1 but the VPN connection is not establish yet so build this vpn
connection so

IKE phase 1 is started.

There are three major steps are taken in the IKE phase 1 which are

1.Negotiation
In this step we negotiate

-for what type of hashing algo we use for the hashing - for data integrity

-What type of encryption is used - refering to the symmetrical encryption algo in which we use the same
key to lock and unlock the data - DES , 3DES and AES are the example of all symmetrical algorithm

-They also negotiate for the authentication - how do they prove who they are they could use the digital
certificate because they are manage by the same manager here mgmt server 10.1.1.25 or we can use
the shared secret which is sometime called preshared key which one is selected is depend how we
configure the firewall and what options are available for the negotiation

-They also negotiate for the Deffie Helman means what flavor of the DH we are going to run

DH is amazing protocol what it gives to the firewall is shared secret keys that they can use with the
symmetric algorithm like AES , DES or 3DES and because we are going to establish those keys so we
need some flavor of the DH and the flavor which is selected is based on what they negotiate

so this is the first step

2.Run DH : the purpose to run the DH is to generate the shared secret keys or sometime refer to the
shared secret key material because we are the subset of that content and use those subsets for those
security protocols

3.Authentication : And we are going to authenticate using the method we agreed to in the first step of the
negotiation either with shared secret or with the pre shared key or using digital certificates

As we have done all three steps then we have vpn tunnel established between these two gateways which
is in red in the print screen

** Now the question is does this help bob , no it still doesn't help bob so there next step which help to
transmit the data of the bob system to the server

because till now we have the private tunnel establish between the gateway by negotiating the protocols ,
running the accepted version of the DH and the Authentication of the FWs to each other

so at present state is not for the bob traffic and so what is for the bob traffic is called IKE Phase 2 or
IPSEC phase

IKE Phase 2 :
So what the two gateways do they use the tunnel build during the IKE phase 1 and use this tunnel to build
the IKE phase 2

1.So the first step is to Negotiate which is independent of IKE phase 1 negotiation and they can use the
different encryption for this phase.

So they negotiate SHA for hashing and for the encryption is AES and the next step is to build the IPSEC
tunnel.

In reality the IPsec tunnel is the IKE phase 2 tunnel so this is for the sending data of bob so in the site to
site VPN we have two tunnels IKE phase 1 & IKE phase 2 then it take the bob packet from the FW2 and
the payload is encrypted so reencapsulate it and put into the IPSEC tunnel so if somebody try to sniff
these packets it seems that packets are source from FW2 and destined to firewall 1 the layer 4 protocol is
50 which is ESP protocol and the original packet from the bob computer which contain the IP addresses ,
the payload and everything else will be encrypted payload getting the free ride from one firewall to
another so when FW1 receive the packets it will decrypt them and forward to the server , the server and
bob doesn't know the magic in between them of IPSEC tunnel now what is main difference of IKE version
2 is that they don't break out into two different phase of IKE Phase 1 & 2

Now in the IKE phase 1 there are 6 packets to accomplish the Negotiation , Run DH and Authentication
also called main node however there is an option if you want an aggressive mode in which the IKE phase
1 is done in 3 packets and it is considered as little less secure , just remember that main mode have 6
packets and aggressive mode have 3 packets and they both get the job done in building the IKE phase 1
tunnel
As we see that there are lots of steps involved in building the VPN in IKE Phase 1 & 2 but checkpoint
make it very simple by breaking down them into chunks of pieces and lets talk about on of those which
we called it VPN community

just like family VPN community are the same , you have full mesh every fw is connected to another the
other option is hub and spoke

In our scenario we have hub and spoke community

FWs are called VPN members where the vpn tunnel is always terminate on vpn member in site to site
implementation in checkpoint so if you are wondering who gonna be potential endpoint or potential
endpoint for a vpn tunnel it's always be a fw or a gateway that is running a vpn service and is considered
as a vpn community member now who are these vpn members doing the encryption for and in our case is
10.1.1.0 network and 10.2.2.0 network and we could include the DMZ as well and the devices that we do
the encryption for they are referred to as VPN Domains and it is not necessary that we have only direct
connected networks only we can have the networks which are connected beyond that also considered as
the Domains so when you have the term vpn domain then understand that these are the networks for
which we are doing the VPN tunneling

VPN site : that include the domains in one location you want to encrypt and the vpn member which is FW
and this is refer to site here we have two site as shown in the PS
So this is the beauty that in checkpoint we can easily identify that here the domains , here are the VPN
community that we belong to it's either full mesh or start or the combination of two we specify what type of
encryption we want to do in the IKE phase 1 , we can specify the hashing algo and we can specify for the
authentication to use either the shared secret or the certificate as we don't need the extra certificate
mechanism as here both firewall are managed by the same mgmt server and it will take care of certificate
authority

In the VPN we will disable NAT because it is not needed because if you have both the VPN and NAT then
what happen is that when bob try to communicate to the server and it's IP is natted on the FW2 as
192.168.1.22 IP of FW2 then the server will reply to the firewall IP not on the Bob IP and in the IPSEC
communication is secure so we don't need it and nor should we do NAT on the IPSEC VPN

These are the steps to configure the VPN.

1.Enable the VPN blade on the firewall

2.In the Object properties of the firewall we go to the topology section and in the below section we specify
the VPN domain we can do this in such a way like you say that everything which is not on going to my
external interface is my VPN domain or we can say in very specific way like I only want to include my
10.1.1.0 Network for the VPN domain and I don't want to include any other network so you can be as
granular as you want to be when identifying the VPN domains

3.Then we go to the VPN tab and create the brand new VPN community and we can specify the type of
topology we want to implement here in our case we use the hub and spoke topology and we add our
branch office firewall as a satellite

4.The last step is we add some rules related the vpn in our poliy section in our vpn column and we can
specify the type of traffic that pass through the VPN
Now we move to the implementation of the VPN in checkpoint

We enable IPsec blade on the FW1-HQ & FW2-Branch firewalls


We save and install the policy on the Smart dash board

The next things is to identify the network doamin for which this VPN tunnel will support and to do that we
go to the topology section of the FW objet properties

First we go to the FW1 topology section and define HQ-Inside network for the VPN traffic and then go to
the FW2 and define the domian for the network

Now we have completed the first two steps by enabling the VPN blade and defining the network on both
forewall for the VPN domains respectively
Now the third steps is to create the VPN community for that we have to go to the following location on the
Smartdashboard and click on the IPsec VPN domain

We create the brand new VPN community

Then we define the Center Gateway FW which is our FW1-HQ gateway

Then we go to the Satellite section and define the gateway FW2 which is our satellite gateway
So the cool thing is that if we want the redundant Center gateway we go to the center gateway section
and add the another firewall and select the Mesh center gateway option this will create the center full
mesh redundant gateways.

This gives the opportunity to have fully connectivity at the core level in the hub and spoke environment.
Under Encryption section we have the multiple options IKE v1 & IKE v2 and IKE v1 is selected by
defeault which have the version IKE Phase 1 & 2

under the Encryption suite we have predefine grouping for the DH different flavours which we run so we
select the custom option here and select the following options
Now it gives specific what we can choose on each phase 1 &2 of the tunnels
Remember that the longer the key the better is the security but it will take more cpu cycles to compute

Now we move to the tunnel management

Here we see that the options under the VPN tunnel sharing option is that by default

"one vpn tunnel per subnet pair" what it means that traffic between the different systems in the subnet of
10.1.1.0 & 10.2.2.2.0 share the same tunnel or we can have the other options like that we can have
dedicated tunnel for each host communication

We will use by default option that is One VPN per subnet pair

Now we move to the Advanced option of the VPN if we are using the pre shared secret key then we get
the option here to set it
If we go to the Advanced VPN properties we can do the additional tweaking here like what flavor of the
DH we will use for the IKE phase 1
Here we have the option for the aggressive mode for the IKE phase 1 if we select this option then we
have the 3 packets negotiation for the IKE phase 1

In IKE phase 2 we have the option of the Perfect Forward Secrecy which simply means that you want to
run the DH for the IKE phase 2 also as you know that during the IKE phase 1 we run the DH to generate
the shared secret key material that we can use for the Algorithm and this shared secret material is
borrowed in the IKE phase 2 as well so if you enable the option of the Pefrect Shared secrecy then it says
don't borrow for the old stuff go and run the DH to generate the shared secret material again for the IKE
phase 2 and for that you have to select the option of the Perfect shared secrey option in the IKE phase 2
and we can also specify what flavour of the DH we want to use
By default PFS is not enable so left it disable and there is also lifetime for both the phase of IKE

IKE phase 1 lifetime is set to by default 1440 mins

IKE phase 2 lifetime is set to by default 3600 seconds

As you see the time difference in between the tunnels so that if IKE phase 2 tunnel is timeout and the IKE
phase 1 is still active then the connection when comes in then IKE phase 1 is already establish so IKE
phase 2 will be again rebuilt on the IKE phase 1

From the security prespective the more often the tunnel is regenerated the more secure it is but it also
include additional overhead also

Here the option to disable the NAT on the VPN community so there will be no Natting done on the VPN
community traffic

we select this option


Now we go to the firewall tab and create some rule for the VPN community in FW1

So we add both at source and destination level the HQ-NW & Branch-NW and we allow all the traffic at
Service level and at the VPN tab we add the VPN community

here we add the Our-Corp-2-Branch vpn community and this is the condition for the vpn traffic to pass
between the firewall is that they have to belong to the VPN community defined in the network
Remember that we push this policy on both firewalls FW1 & FW2
and we install this policy
Now we are tryping to ping the system in branch office which is 10.2.2.222 from the system in the HQ
having IP 10.1.1.50 and make sure that ICMP option is enable in the global properties this request trigger
the IPSEC
at this time it doesn't work then we try to figure out what is the reason for this issue

We go to the Smart view tracker to figure this out why this happened
As we see in the View tracker that packet is dropped because due to the rule 2 which says that anything
other than the mgmt traffic to the firewall is being dropped so that is why this traffic is not passing through
the firewall so we have to make changes in the rule of the firewall
we will disable the rule number 2 for the time being
and then install the policy again and then try to run the ping again from the above mentioned systems

This time it is working


This is IKE phase 1 traffic as mentioned below in the printscreen that we are looking for

Now we are looking into the IKE phase 2 tunnel traffic


This screenshot shows the encrypted messages
Here we are seeing that IKE 500 UDP this port is used for the IKE phase 1 negotiation

and we have the rule 0 which is the implied rule and remember that implied rule are applied before the
explict rule in the checkpoint firewall
We have the implied rule for the VPN traffic and for the mgmt traffic for the success

At the cli level we have the utility called vpn tunnel utility it's a menu driven cmd line utility and if want to
list all IKE SAs as we are using IKE V1 which have two phases and then select the option 1 which shows
the IKE phase 1 tunnel and SA stand for security Association which is the aggreement that we have in
between our firewall and the peer firewall

by pressing enter we get the menu and if you want to see the IPSEC SAs security association then press
the option 2 and here you get the security parameter indexes for your IKE phase 2 tunnel and for the IKE
phase 2 tunnel they are break into two components there are Inbound channel and outbound channel and
each one different SPI (security parameter Index) for the SAs inside the tunnel
Suppose we want to wipe out the specific IKE phase 1 or IKE phase 2 tunnel

So there are lots of options for them option 5& 6 says that we can delete the IKE phase 2 tunnel

option 5 is for gateway and option 6 is for remote access vpn client

If we want to be aggressive then we can choose the option number 7 which says that we can delete the
IKE Phase 1 &2 for the specific gateway that will wipe out which is going between in ourself and the peer
that we specify

Option 0 says delete all IPSEC and IKE phase 1 for all peers and for all users so if we press 0 then it will
basically all wipe all out
And we select the option 1 then it shows nothing here

So if we initiate the ping from the client which again initiate the vpn tunnel and it has some delay also

You might also like