In this lesson,
we're going to talk all about IPSec.
Now, IPSec is a secure network protocol suite
that provides authentication
and encryption of data packets
to create a secure encrypted communication path
between two computers over an internet protocol network.
IPSec is the most popular protocol in use today
for the creation and operation of VPNs,
or virtual private networks.
IPSec provides confidentiality, integrity, authentication,
and anti-replay when using a VPN connection
for both site-to-site and client-to-site VPNs.
IPSec provides confidentiality by using data encryption.
It's also going to provide integrity
by ensuring the data was not modified in transit by checking
that its hash before transmission and upon receipt match.
Authentication is going to be provided
by having each party verify that they are
who they claim to be.
And IPSec is also going to provide you with anti-replay
by checking the sequence numbers
on all the packets prior to transmission.
This prevents the transmission of a duplicate packet,
and it prevents an attacker from being able to capture
and resend packets later as part of an attack.
Before we go too deep into IPSec,
let's take a big picture view of how IPSec works.
There are five main steps in the process of establishing
and using a secure VPN tunnel when you're using IPSec.
First, there's a request to start a key exchange.
Second, IKE phase one is going to authenticate the parties
and establish a secure channel for negotiation.
Third, IKE phase two is going to negotiate
the security association parameters
and fully establish the secure tunnel.
Fourth, we're going to have data transfer,
and this is going to allow data transfer
between the two parties over the secure tunnel
to occur using the IPSec parameters
and keys stored from the security associations
that were negotiated back in step three.
Fifth IPSec tunnel termination's going to occur,
and this happens when the security associations are
terminated through either mutual agreement and deletion
or due to timing out of the tunnel due
to one party becoming non-responsive.
All right, those are our five main steps,
but it's important for us to fully understand
how all this works in our networks,
so that we can better troubleshoot these IPSec tunnels
if we ever have a problem with or not working properly.
Now, the first step is pretty self-explanatory here.
We need to request to start a key exchange.
This can be done by your devices automatically
if you're using a site-to-site VPN,
or it can be initiated by a software client
on your laptop if you're going to be using
a client-to-site method.
Either way, the request
to initiate a VPN connection is going to occur,
and then we can move to our second step, the IKE phase one.
Now, during IKE phase one,
the IPSec peers have their identities authenticated
and encrypted for protection.
Then there's going to be a negotiation
that occurs to create a matching IKE SA,
or internet key exchange security association,
between the two IPSec peers
to protect the key exchange that's about to occur.
Next, the IPSec peers are going to perform
an authenticated Diffie-Hellman key exchange,
so that both IPSec peers will have a copy
of the same shared secret key,
and that way they can use that to establish
and secure an IKE phase two tunnel.
The internet key exchange, or IKE phase one,
can use one of two modes to conduct this process.
We can use either main mode or aggressive mode.
Now, when we're using main mode,
it's going to conduct three two-way
exchanges between the peers.
This goes from the initiator to the receiver.
Now the first exchange between the IPSec peers is
to agree upon which algorithms and hashes are going to be used
to secure the IKE communications throughout this process.
The second exchange that they're going to do is going to be
between the peers using a Diffie-Hellman key exchange
to generate the shared secret key material that's going
to be used to create these shared secret keys
that we can then send to the other party
by sending an assigned random number,
and that way the two parties can prove their identities.
Then we're going to have a third exchange
between the IPSec peers, and this occurs
so that each side can verify the identity
of the other side by looking at an encrypted form
of the other peer's IP address.
Now, by the time these three exchanges are finished,
both peers have received matching IKE security associations
or IKE SAs.
These can now be used for ISAKMP exchanges
between the IPSec peers, moving forward
throughout the rest of the process.
These security associations are going to contain
the authentication methods used by the peers.
The encryption and hash algorithms used,
the Diffie-Hellman groups used,
the expiration of the IKE SA, and the shared secret values
for the encryption algorithms.
Basically, these IKE SAs have everything
that both peers need in order to make
and maintain their IPSec tunnels.
Now, the second mode you can use is known
as aggressive mode, and this has fewer exchanges
than the main mode.
So instead of having three, we're going to have less.
This results in fewer packets
and a faster initial connection than using main mode.
Now in aggressive mode, almost everything needed
for the proposed security association
is going to be sent by the initiator at first.
This includes the Diffie-Hellman public key,
the signed random number, and an identity packet.
Then it's going to be received,
and the receiver is going to send everything back at once.
So the initiator only needs to confirm the exchange
to finish the association.
This is why it's considered more aggressive
because one side is saying,
here's all the things I want to use,
and the second side can say, okay, I'll go along with that.
Now, this is considered less secure than main mode,
but again, it's a lot faster than using main mode
'cause we don't have to go through these three passes
and three exchanges.
Now, once you have the IKE security associations,
and they've been received by either using main mode
or aggressive mode, we can move
into step three of our process.
This is the IKE phase two portion
of our tunnel establishment.
Now, the purpose of IKE phase two is
to negotiate IPSec security associations
to set up the IPSec tunnel.
IKE phase two is used to negotiate the IPSec
Security Association parameters that are protected
by the existing IKE SA that we created in phase one.
This allows us to establish IPSec security associations
to periodically renegotiate security associations
we need to maintain that security
and to perform additional Diffie-Hellman key exchanges
if we need to.
During IKE phase two, we can accomplish this
by using quick mode.
Now, quick mode can only occur
after IKE has already been established
in that secure tunnel during phase one,
using either main or aggressive modes.
Using quick mode, we can negotiate a shared IPSec policy,
and we can also derive shared secret key materials
using the IPSec security algorithms,
and then we can use that to establish our IPSec SAs.
Now, as discussed in phase one,
each SA has a limited lifespan, and it will then expire.
Now with quick mode, we can negotiate a replacement SA
before the expiration occurs,
and this lets us maintain that VPN tunnel
for longer periods of time without worrying
that the attacker could crack
our security associations and enter that tunnel.
Now the fourth step of this process is
to conduct our data transfer
with those newly established encrypted IPSec tunnels.
This is done by using IPSec SAs
that were created in IKE phase two.
Now, these packets are going to be encrypted by the sender,
and they're going to be decrypted by the receiver,
and this makes sure everything
is kept confidential and secure.
Now, our fifth and final step of this process is
to terminate the tunnel.
This occurs whenever the IPSec SAs are deleted
by mutual agreement by both peers,
or if the SAs reach their lifetime expiration
and simply time out without being replaced.
When this happens, we need to go and create a new phase one
and phase two key exchange if we want to reestablish
that tunnel and conduct more data transfers.
Now, you may or may not understand the basics
of asymmetric cryptography yet,
so let me take a quick detour
and explain how this whole key exchange thing works.
You may have noticed I kept saying the words Diffie-Hellman.
I kept talking about a Diffie-Hellman exchange.
Well, Diffie and Hellman are basically names
of two computer scientists who came up
with this really brilliant way for two systems
that don't know each other to be able
to exchange a secret key and trust each other.
This process is known
as the Diffie-Hellman Key Exchange named after them.
So in IKE phase one, there's an initial tunnel created
between the two peers, and they're going to begin
to exchange some information to create those IKE SAs,
or security associations,
and then authenticate each other.
Now, in a Diffie-Hellman key exchange,
the two clients, in this case PC1 and PC2,
are going to create their own private key,
and I'm labeling these PRI for private.
From that key, they can use a mathematical algorithm
to calculate a corresponding public key,
and then they can hand that public key
to the other PC to create a key exchange.
Now, PC2 has a private key called PC2 PRI,
and they have a public key for PC1 called PC1 PUB.
PC1 has its private key PC1 PRI,
and a public key for PC2 called PC2 PUB.
Now at this point, each side is going to calculate
a shared secret using the Diffie-Hellman protocol
by using their private key and the other person's public key
and this mathematical algorithm,
they get a Diffie-Hellman's shared key,
which is going to be the same on both sides,
and now they both have the same shared secret.
They can now create a tunnel with it.
At this point, they both agree to the encryption
and the integrity methods,
and they're going to establish their IKE phase two tunnel
using that Diffie-Hellman key.
At this point, they're going to use the IPSec tunnel created,
and that becomes known as a phase two key
that's going to create this IPSec tunnel and secure it.
Once they have this phase two key in use,
they now have encryption and integrity intact
for this tunnel, and it becomes the tunnel
inside of a tunnel, and now we have a secure method
to communicate between the two peers.
Now I know that was a lot, so let me break it down again
into just five steps, and show you
what it looks like in the real world.
First, I have PC1, and they want to send traffic to PC2.
When they do this, router one is going to create an initiation
of an IPSec tunnel.
Second, we're going to see router one and router two,
and they start negotiating the security associations
to form the IPSec IKE phase one tunnel.
This is also known as our ISAKMP tunnel.
Now in step three, the IKE phase two
is going to create this tunnel inside
of the tunnel when it's negotiated and set up.
Now, once that tunnel is established, we can begin
to conduct data transfer in step four,
and the information starts flowing
between PC1 and PC2 securely.
When they're all done with that, we reach step five
and the tunnel is going to be torn down
and the IPSec security associations are going to be deleted.
Now, if you wanted to be able to create another VPN,
you can do that by starting this whole process over
from the beginning and going through those five steps again.
All right, at this point, we've covered
the tunnel establishments a few different times
in a few different ways,
so hopefully it's beginning to make some sense.
The reason I covered this so many times,
in so many different ways is this is an area
that a lot of people struggle with.
Now, to allow the data transfer to happen,
there are two methods that we can use.
These are known as transport mode or tunneling mode.
Now, transport mode is going to use
the packet's original IP header,
and it's used for client-to-site VPNs.
This approach works really well
if you have problems increasing your packet size
because you may end up hitting
a maximum transmitted unit size,
or MTU, inside your network.
Remember by default, the MTU,
or maximum transmission unit size,
is set at 1,500 bytes in most networks.
If you go over 1,500 bytes,
the packet will become fragmented,
and this can cause issues with your VPN's functionality.
If you're using a client-to-site VPN,
I highly recommend you use transport mode
as your IPSec method because it doesn't add
additional padding to your packet
and doesn't increase its size.
Now, on the other hand, if you're setting up
a site-to site-VPN, like having a regional office
connecting back to a main office,
then I would use tunneling mode.
Now, tunneling mode is used to encapsulate the entire packet
and put another header on top of it.
This is going to increase the size of that packet,
and it could go over your MTU.
Now think about it this way.
Let's say you had an envelope,
and you put it inside another envelope
and then wrote an address on it, you readdressed it,
and then you shipped it to somebody else.
This new header is going to have a new source
and destination of the VPN terminating devices
at the different site that it wants to go to.
When it gets to the other site,
the VPN concentrator is going to remove that outer envelope
or that header inside of a network packet,
decrypt the content, and then route it
across their private local area network
just as if it was coming
from an internally connected client.
When using tunneling mode,
you're encapsulating the entire packet
into a new packet, so this is going to increase the size
of your overall packet, and it could go above
that MTU default size of 1,500 bytes.
If you're going to be using a site-to-site VPN, you may need
to allow jumbo frames, which is any frame
above an MTU size of 1,500 bytes.
This way, it'll be properly supported.
Normally, the best way to configure your devices would be
to drop your maximum MTU size on your inner router
to something like 1,400 bytes,
and then connect it to the VPN.
This way, there's enough room to add the extra encapsulation
and the new packet header before transmitting it
out over the public internet inside your VPN tunnel.
If you control the entire network,
you could actually raise your MTU size up
to a maximum of 9,000 bytes if you wanted to,
but this should only be done on your own local area networks
'cause 9,000 byte packets will have
trouble traversing the internet.
Now remember, transport mode is normally going to be used
for client-to-site VPNs, and tunneling mode
is normally going to be used for site-to-site VPNs.
The final thing we need to discuss
in this lesson is the concept
of an authentication header, or AH,
and an encapsulating security payload,
or ESP, within your IPSec protocol.
Now, the AH, or authentication header, is used
to provide connectionless data integrity
and data origin authentication for IP datagrams,
and it provides protection against replay attacks.
Be aware though that the authentication header does not
provide any kind of confidentiality of the data itself.
Instead, the authentication header contains
a cryptographic hash of the data,
and this acts as identification information
to provide the integrity between the sender
and the receiver of each packet being transmitted.
Now, the encapsulating security payload,
or ESP, is used to provide authentication, integrity,
replay protection, and confidentiality of the data.
By using ESP within IPSec, you can rewrite the payload
of the packet inside of an encrypted format.
Now, with ESP, we're only protecting the confidentiality
of the payload contained within the packet,
not the headers themself.
So if you're using transport mode,
such as in a client-to-site VPN,
you can use the authentication header
to provide integrity for your TCP header,
and then you can add the ESP,
encapsulating security payload,
to encrypt the TCP header and the data in the payload.
But this does not encrypt the end-to-end header,
so people outside your organization can see
where the data's coming from and where it's going to.
If you're using the tunneling mode,
such as in a site-to-site VPN,
you can instead use both the authentication header
and the encapsulating security payload
to provide integrity and encryption of that payload,
including the end-to-end header.
In this case, a new IP header is going to be added
to the front of the packet to cover the hops
to the other end of the secure connection.
This means that nobody on the internet can see the source
or destination of the traffic within the organization's
internal networks on either side of this VPN connection.