I want to take some time now to talk about a couple of additional
concepts with regards to IPsec and the implementations.
I'm about to revisit the SA conversation that we had in the previous module.
As we discussed,
we have both the ISAKMP SA and the IPsec SA that are formed
when establishing an IPsec connection.
The ISAKMP SA, which can also be referred to as the IKE SA,
is used to protect the negotiation of the actual traffic SAs,
or the IPsec SAs.
Its sole purpose is to establish SAs to help us securely establish other SAs.
The traffic SAs are those IPsec SAs.
These IPsec security associations are the unidirectional ones,
so you need two to establish a bidirectional connection.
Since IKE helps us establish these IPsec SAs securely,
the IKE SA would be considered the parent.
I'm bringing this up because sometimes you'll hear the
IPsec ones being referred to as a child SA,
which is true.
Since IKE helped us establish those SAs, they are children of the IKE SAs.
So the concept of child security associations is that
they're derived from the parent, or IKE SA,
as a part of its function and purpose.
NAT-Traversal, or NAT-T, is something that I want to talk about for a minute,
as this is very important to organizations deploying IPsec in the enterprise.
We saw it in the previous demo in action, but let me explain it a little bit.
The problem that we face is that ESP doesn't have a
specific port number assigned to it.
Because of this,
what will happen if we try to implement this in an
organization that uses Port Address Translation,
or PAT?
There's no specific ports to translate to allow us to utilize IPsec,
so the ESP traffic cannot pass through the PAT device.
We can't change the port for translation if it doesn't exist.
So here comes the solution to the problem: NAT-T.
What this does is two things.
First, it detects if NAT-T is supported on both ends of the connection.
If there are,
our ESP packets get encapsulated inside of another packet on UDP port
4500 for both the source and destination ports.
Because of this encapsulation,
our ESP packets can be translated via PAT and sent
to its destinations accordingly.
So we talked about a lot of things with regards to IPsec and its many
different implementations in enterprise environments.
We started off the conversation by discussing site-to-site VPNs
and remote access VPNs and what they are.
They both serve very different purposes,
from protecting a network to protecting a device or
providing access to resources.
We then dove into the various implementations that are possible for
IPsec and highlighted a few that have specific uses.
Then, we detailed DMVPN in IPsec and hopped into the lab to configure,
debug, and analyze them.
After that, we did the same thing,
but for a remote access VPN using a commercial service.
Finally,
we talked about a few extra items that are important to the IPsec concepts.
Coming up,
we're going to be detailing IKE version 1 and learning
all about its modes and functionality. See you in the next module.