In this video I'm going to share with you a topic regarding
IPsec that's really important.
It happens by default for a lot of our implementations,
but being aware of it will help you troubleshoot it
if it's not going well.
And that is the concept of NAT traversal.
Also sometimes called NAT transparency.
So let's use this topology and imagine we have our own access
VPN, a site-to-site .
VPN if there is a NAT device or more-- or worse even,
a PAT device in between the client or the other end
of the tunnel, what could happen is a PAT device, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of the tunnel, what could happen is a PAT device,
if it's doing port address translation, it may see this.
It may see-- at layer 4, it may see protocol number
50, which is ESP.
And it may say, I don't know how to track that.
I can't.
And if you have a NAT-- a PAT device
in the path that can't handle tracking
ESP because it's not a TCP or UDP protocol,
and it doesn't have a port associated those two,
if it fails that will cause our tunnel to break.
So during the initial negotiations,
this is true for IKEv1 with many implementations
and IKE version 2 in all, because it's
part of the standard. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
part of the standard.
They can detect based on a hash that they do on the IP address.
They'll generate a hash based on what their IP address is
the receiver can check that hash and say, whoa,
that hash doesn't match the hash I generated for that IP.
We must be going through some kind
of NAT device or PAT device.
And if they detect that, then for the IPsec tunnel,
they can go ahead, and they can go ahead and use UDP.
So the traffic will look like this.
Here's the payload.
Then we have the ESP header with all of the payload encrypted,
including the original IP addresses.
And then what we do is we tack on a layer 4 UDP header. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then what we do is we tack on a layer 4 UDP header.
And that's just for the benefit of the NAT traversal.
And the client, if it's a Windows client,
maybe it picked a free port, maybe
it picked like 38,000 and change or something.
And it's going to go to the port they agreed to,
which in many cases is 4,500.
So what we would see for the IPsec tunnel
is we'd see a packet sourced from the PC going
to the hidden device.
That would be the outside IP address PC
and router 1 as the IP header at layer 3,
and then the next protocol would be protocol 17, which is UDP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then the next protocol would be protocol 17, which is UDP.
And then in the UDP, it would have
as the next thing that came in would be the ESP header.
And then after that we'd have the encrypted payload.
So that way, R1 could strip all that away,
decrypt the packet, and then forward it
onto its destination.
In fact, you know what?
Let me show you what a packet like that looks
like with a protocol analyzer.
In fact, let me back up just a little bit
and let me share with you the initial negotiations.
This is also true for IKEv1 and also IKEv2.
The Cisco environment, IKEv1 will do the NAT detection WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The Cisco environment, IKEv1 will do the NAT detection
and IKEv2 is part of the standard.
So here's a packet coming from a client to a server at 15.1.1.1.
It's an ISAKMP exchange.
And I want to point out here at layer 4,
we're going to do that first initial negotiation on UDP port
500.
So before we actually build the tunnels,
we're going to start the negotiations.
This is true for IKE phase 1.
It's also true for IKE version 2 with the IKEv2 SA
that they establish.
They're going to start the ball rolling
by going to UDP port 500. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
by going to UDP port 500.
So that's being shown right here in the Ethernet header going
to UDP.
And the UDP destination port is 500, where the client just
grabbed a free port, 59704, used it, and started the negotiation
process.
Inside of this negotiation, here's what the client said.
The client said, here's all the things I can support,
including down here NAT detection
regarding the source IP and NAT detection regarding
the destination IP.
So they negotiated the session.
And if we scroll down and we get down to the IPsec ESP packet,
check this out.
Here's a packet coming from our client going to the server. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Here's a packet coming from our client going to the server.
But if we look at the layer 3 header here,
the layer 3 header says the next protocol is UDP,
protocol number 17 in decimal.
And then after that, check this out.
It has the UDP encapsulation of the IPsec packets.
This is my packet tracer who's telling me what's happening.
But the destination port, check that out.
The destination port is 4,500.
So the sessions between the client and the server
will appear to the internet as just being UDP packets or UDP
segments between those two port numbers using UDP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
segments between those two port numbers using UDP.
And then after the UDP header, we have the ESP information.
So there's these security parameter index, a sequence
number, and then the payload behind that is all encrypted.
So if you're doing protocol analysis
or you're setting up firewall rules
about which ports and protocols to allow through,
you want to make sure we allow the UDP port 500
for the initial negotiation, whether it's IKE version 1
or IKE version 2.
The initial negotiation is going to be UDP port 500.
And then with NAT traversal, or NAT transparency
they call it sometimes, it's going to be UDP port 4500. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they call it sometimes, it's going to be UDP port 4500.
So we want to make sure that that's allowed,
those protocols are allowed between the endpoints
of our VPN tunnel.
And that is true whether it's a remote-access VPN
client or the other end of a site-to-site tunnel.
Another problem that NAT traversal
solves by injecting that UDP header for the ESP traffic
is that even if we have a NAT device that says, yeah,
I get it.
I can do a translation for ESP.
No problem, I can do it.
How long is that translation going to stay there?
Because you might have an IPsec tunnel
that has no traffic for a while.
And if some NAT device in the middle drops the translation, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if some NAT device in the middle drops the translation,
that's going to break your tunnel.
So in addition to the NAT traversal,
we also have the ability to keepalives.
That way we're sending packets at an interval, just
a keepalive packet, to keep that translation on a NAT device
that's between the two peers to keep it active and working.
So that's another benefit of NAT traversal.
So thanks for joining me in this video.
And I'll see you in the next one.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.