WEBVTT

1
00:00.000 --> 00:00.382 align:middle line:84%


2
00:00.382 --> 00:02.840 align:middle line:90%
In this video I'm going to
share with you a topic regarding

3
00:02.840 --> 00:04.260 align:middle line:84%
IPsec that's really important.

4
00:04.260 --> 00:06.770 align:middle line:90%
It happens by default for a
lot of our implementations,

5
00:06.770 --> 00:09.170 align:middle line:90%
but being aware of it will
help you troubleshoot it

6
00:09.170 --> 00:10.490 align:middle line:84%
if it's not going well.

7
00:10.490 --> 00:12.950 align:middle line:90%
And that is the concept
of NAT traversal.

8
00:12.950 --> 00:15.418 align:middle line:90%
Also sometimes called
NAT transparency.

9
00:15.418 --> 00:17.960 align:middle line:90%
So let's use this topology and
imagine we have our own access

10
00:17.960 --> 00:19.190 align:middle line:84%
VPN, a site-to-site .

11
00:19.190 --> 00:24.040 align:middle line:90%
VPN if there is a NAT device
or more-- or worse even,

12
00:24.040 --> 00:27.830 align:middle line:90%
a PAT device in between
the client or the other end

13
00:27.830 --> 00:30.560 align:middle line:90%
of the tunnel, what could
happen is a PAT device,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:27.830 --> 00:30.560 align:middle line:90%
of the tunnel, what could
happen is a PAT device,

14
00:30.560 --> 00:33.350 align:middle line:90%
if it's doing port address
translation, it may see this.

15
00:33.350 --> 00:36.500 align:middle line:90%
It may see-- at layer 4,
it may see protocol number

16
00:36.500 --> 00:38.600 align:middle line:84%
50, which is ESP.

17
00:38.600 --> 00:41.060 align:middle line:90%
And it may say, I don't
know how to track that.

18
00:41.060 --> 00:41.870 align:middle line:84%
I can't.

19
00:41.870 --> 00:43.370 align:middle line:90%
And if you have a
NAT-- a PAT device

20
00:43.370 --> 00:45.350 align:middle line:90%
in the path that
can't handle tracking

21
00:45.350 --> 00:48.790 align:middle line:90%
ESP because it's not
a TCP or UDP protocol,

22
00:48.790 --> 00:50.990 align:middle line:90%
and it doesn't have a
port associated those two,

23
00:50.990 --> 00:53.090 align:middle line:90%
if it fails that will
cause our tunnel to break.

24
00:53.090 --> 00:55.050 align:middle line:90%
So during the
initial negotiations,

25
00:55.050 --> 00:57.605 align:middle line:90%
this is true for IKEv1
with many implementations

26
00:57.605 --> 00:59.655 align:middle line:90%
and IKE version 2
in all, because it's

27
00:59.655 --> 01:00.530 align:middle line:84%
part of the standard.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
00:59.655 --> 01:00.530 align:middle line:84%
part of the standard.

28
01:00.530 --> 01:03.885 align:middle line:90%
They can detect based on a hash
that they do on the IP address.

29
01:03.885 --> 01:06.260 align:middle line:90%
They'll generate a hash based
on what their IP address is

30
01:06.260 --> 01:08.720 align:middle line:90%
the receiver can check
that hash and say, whoa,

31
01:08.720 --> 01:11.293 align:middle line:90%
that hash doesn't match the
hash I generated for that IP.

32
01:11.293 --> 01:12.710 align:middle line:90%
We must be going
through some kind

33
01:12.710 --> 01:14.480 align:middle line:84%
of NAT device or PAT device.

34
01:14.480 --> 01:17.570 align:middle line:90%
And if they detect that,
then for the IPsec tunnel,

35
01:17.570 --> 01:20.442 align:middle line:90%
they can go ahead, and they
can go ahead and use UDP.

36
01:20.442 --> 01:21.900 align:middle line:90%
So the traffic will
look like this.

37
01:21.900 --> 01:22.817 align:middle line:84%
Here's the payload.

38
01:22.817 --> 01:25.400 align:middle line:90%
Then we have the ESP header with
all of the payload encrypted,

39
01:25.400 --> 01:27.450 align:middle line:90%
including the
original IP addresses.

40
01:27.450 --> 01:31.652 align:middle line:90%
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

40
01:27.450 --> 01:31.652 align:middle line:90%
And then what we do is we
tack on a layer 4 UDP header.

41
01:31.652 --> 01:33.860 align:middle line:90%
And that's just for the
benefit of the NAT traversal.

42
01:33.860 --> 01:36.080 align:middle line:90%
And the client, if
it's a Windows client,

43
01:36.080 --> 01:37.730 align:middle line:90%
maybe it picked a
free port, maybe

44
01:37.730 --> 01:41.340 align:middle line:90%
it picked like 38,000
and change or something.

45
01:41.340 --> 01:43.490 align:middle line:90%
And it's going to go to
the port they agreed to,

46
01:43.490 --> 01:45.830 align:middle line:84%
which in many cases is 4,500.

47
01:45.830 --> 01:47.600 align:middle line:90%
So what we would see
for the IPsec tunnel

48
01:47.600 --> 01:51.155 align:middle line:90%
is we'd see a packet
sourced from the PC going

49
01:51.155 --> 01:52.030 align:middle line:84%
to the hidden device.

50
01:52.030 --> 01:53.960 align:middle line:90%
That would be the
outside IP address PC

51
01:53.960 --> 01:58.040 align:middle line:90%
and router 1 as the
IP header at layer 3,

52
01:58.040 --> 02:01.550 align:middle line:90%
and then the next protocol would
be protocol 17, which is UDP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

52
01:58.040 --> 02:01.550 align:middle line:90%
and then the next protocol would
be protocol 17, which is UDP.

53
02:01.550 --> 02:03.440 align:middle line:90%
And then in the
UDP, it would have

54
02:03.440 --> 02:06.350 align:middle line:90%
as the next thing that came
in would be the ESP header.

55
02:06.350 --> 02:08.789 align:middle line:90%
And then after that we'd
have the encrypted payload.

56
02:08.789 --> 02:11.375 align:middle line:90%
So that way, R1 could
strip all that away,

57
02:11.375 --> 02:13.000 align:middle line:90%
decrypt the packet,
and then forward it

58
02:13.000 --> 02:13.970 align:middle line:84%
onto its destination.

59
02:13.970 --> 02:14.928 align:middle line:84%
In fact, you know what?

60
02:14.928 --> 02:16.970 align:middle line:90%
Let me show you what a
packet like that looks

61
02:16.970 --> 02:19.130 align:middle line:84%
like with a protocol analyzer.

62
02:19.130 --> 02:21.170 align:middle line:90%
In fact, let me back
up just a little bit

63
02:21.170 --> 02:23.840 align:middle line:90%
and let me share with you
the initial negotiations.

64
02:23.840 --> 02:28.810 align:middle line:90%
This is also true for
IKEv1 and also IKEv2.

65
02:28.810 --> 02:31.880 align:middle line:90%
The Cisco environment, IKEv1
will do the NAT detection
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
02:28.810 --> 02:31.880 align:middle line:90%
The Cisco environment, IKEv1
will do the NAT detection

66
02:31.880 --> 02:33.840 align:middle line:90%
and IKEv2 is part
of the standard.

67
02:33.840 --> 02:38.690 align:middle line:90%
So here's a packet coming from a
client to a server at 15.1.1.1.

68
02:38.690 --> 02:40.310 align:middle line:84%
It's an ISAKMP exchange.

69
02:40.310 --> 02:42.530 align:middle line:90%
And I want to point
out here at layer 4,

70
02:42.530 --> 02:46.370 align:middle line:90%
we're going to do that first
initial negotiation on UDP port

71
02:46.370 --> 02:47.360 align:middle line:84%
500.

72
02:47.360 --> 02:49.257 align:middle line:90%
So before we actually
build the tunnels,

73
02:49.257 --> 02:50.840 align:middle line:90%
we're going to start
the negotiations.

74
02:50.840 --> 02:52.610 align:middle line:84%
This is true for IKE phase 1.

75
02:52.610 --> 02:56.330 align:middle line:90%
It's also true for IKE
version 2 with the IKEv2 SA

76
02:56.330 --> 02:57.225 align:middle line:84%
that they establish.

77
02:57.225 --> 02:58.850 align:middle line:90%
They're going to
start the ball rolling

78
02:58.850 --> 03:00.760 align:middle line:84%
by going to UDP port 500.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
02:58.850 --> 03:00.760 align:middle line:84%
by going to UDP port 500.

79
03:00.760 --> 03:03.480 align:middle line:90%
So that's being shown right here
in the Ethernet header going

80
03:03.480 --> 03:04.580 align:middle line:84%
to UDP.

81
03:04.580 --> 03:07.040 align:middle line:90%
And the UDP destination port
is 500, where the client just

82
03:07.040 --> 03:11.150 align:middle line:90%
grabbed a free port, 59704, used
it, and started the negotiation

83
03:11.150 --> 03:12.050 align:middle line:84%
process.

84
03:12.050 --> 03:15.140 align:middle line:90%
Inside of this negotiation,
here's what the client said.

85
03:15.140 --> 03:17.880 align:middle line:90%
The client said, here's all
the things I can support,

86
03:17.880 --> 03:19.760 align:middle line:90%
including down
here NAT detection

87
03:19.760 --> 03:22.100 align:middle line:90%
regarding the source IP
and NAT detection regarding

88
03:22.100 --> 03:23.420 align:middle line:84%
the destination IP.

89
03:23.420 --> 03:25.080 align:middle line:84%
So they negotiated the session.

90
03:25.080 --> 03:28.400 align:middle line:90%
And if we scroll down and we get
down to the IPsec ESP packet,

91
03:28.400 --> 03:29.370 align:middle line:84%
check this out.

92
03:29.370 --> 03:32.540 align:middle line:90%
Here's a packet coming from
our client going to the server.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
03:29.370 --> 03:32.540 align:middle line:90%
Here's a packet coming from
our client going to the server.

93
03:32.540 --> 03:34.660 align:middle line:90%
But if we look at the
layer 3 header here,

94
03:34.660 --> 03:37.400 align:middle line:90%
the layer 3 header says
the next protocol is UDP,

95
03:37.400 --> 03:39.620 align:middle line:84%
protocol number 17 in decimal.

96
03:39.620 --> 03:41.740 align:middle line:90%
And then after that,
check this out.

97
03:41.740 --> 03:44.850 align:middle line:90%
It has the UDP encapsulation
of the IPsec packets.

98
03:44.850 --> 03:47.622 align:middle line:90%
This is my packet tracer who's
telling me what's happening.

99
03:47.622 --> 03:49.330 align:middle line:90%
But the destination
port, check that out.

100
03:49.330 --> 03:51.470 align:middle line:84%
The destination port is 4,500.

101
03:51.470 --> 03:53.870 align:middle line:90%
So the sessions between
the client and the server

102
03:53.870 --> 03:57.050 align:middle line:90%
will appear to the internet as
just being UDP packets or UDP

103
03:57.050 --> 04:00.590 align:middle line:90%
segments between those two
port numbers using UDP.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

103
03:57.050 --> 04:00.590 align:middle line:90%
segments between those two
port numbers using UDP.

104
04:00.590 --> 04:03.545 align:middle line:90%
And then after the UDP header,
we have the ESP information.

105
04:03.545 --> 04:05.870 align:middle line:90%
So there's these security
parameter index, a sequence

106
04:05.870 --> 04:10.250 align:middle line:90%
number, and then the payload
behind that is all encrypted.

107
04:10.250 --> 04:11.960 align:middle line:90%
So if you're doing
protocol analysis

108
04:11.960 --> 04:13.550 align:middle line:90%
or you're setting
up firewall rules

109
04:13.550 --> 04:16.010 align:middle line:90%
about which ports and
protocols to allow through,

110
04:16.010 --> 04:18.920 align:middle line:90%
you want to make sure we
allow the UDP port 500

111
04:18.920 --> 04:22.220 align:middle line:90%
for the initial negotiation,
whether it's IKE version 1

112
04:22.220 --> 04:23.000 align:middle line:84%
or IKE version 2.

113
04:23.000 --> 04:25.520 align:middle line:90%
The initial negotiation is
going to be UDP port 500.

114
04:25.520 --> 04:27.920 align:middle line:90%
And then with NAT traversal,
or NAT transparency

115
04:27.920 --> 04:31.337 align:middle line:90%
they call it sometimes, it's
going to be UDP port 4500.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
04:27.920 --> 04:31.337 align:middle line:90%
they call it sometimes, it's
going to be UDP port 4500.

116
04:31.337 --> 04:33.170 align:middle line:90%
So we want to make sure
that that's allowed,

117
04:33.170 --> 04:35.212 align:middle line:90%
those protocols are allowed
between the endpoints

118
04:35.212 --> 04:36.050 align:middle line:84%
of our VPN tunnel.

119
04:36.050 --> 04:38.480 align:middle line:90%
And that is true whether
it's a remote-access VPN

120
04:38.480 --> 04:41.210 align:middle line:90%
client or the other end
of a site-to-site tunnel.

121
04:41.210 --> 04:42.950 align:middle line:90%
Another problem
that NAT traversal

122
04:42.950 --> 04:46.550 align:middle line:90%
solves by injecting that UDP
header for the ESP traffic

123
04:46.550 --> 04:48.830 align:middle line:90%
is that even if we have a
NAT device that says, yeah,

124
04:48.830 --> 04:49.330 align:middle line:84%
I get it.

125
04:49.330 --> 04:51.330 align:middle line:84%
I can do a translation for ESP.

126
04:51.330 --> 04:52.730 align:middle line:84%
No problem, I can do it.

127
04:52.730 --> 04:54.867 align:middle line:90%
How long is that translation
going to stay there?

128
04:54.867 --> 04:56.450 align:middle line:90%
Because you might
have an IPsec tunnel

129
04:56.450 --> 04:57.870 align:middle line:84%
that has no traffic for a while.

130
04:57.870 --> 05:00.743 align:middle line:90%
And if some NAT device in the
middle drops the translation,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

130
04:57.870 --> 05:00.743 align:middle line:90%
And if some NAT device in the
middle drops the translation,

131
05:00.743 --> 05:02.160 align:middle line:90%
that's going to
break your tunnel.

132
05:02.160 --> 05:04.640 align:middle line:90%
So in addition to
the NAT traversal,

133
05:04.640 --> 05:07.230 align:middle line:90%
we also have the
ability to keepalives.

134
05:07.230 --> 05:09.470 align:middle line:90%
That way we're sending
packets at an interval, just

135
05:09.470 --> 05:12.490 align:middle line:90%
a keepalive packet, to keep
that translation on a NAT device

136
05:12.490 --> 05:16.050 align:middle line:90%
that's between the two peers
to keep it active and working.

137
05:16.050 --> 05:17.965 align:middle line:90%
So that's another
benefit of NAT traversal.

138
05:17.965 --> 05:19.590 align:middle line:90%
So thanks for joining
me in this video.

139
05:19.590 --> 05:20.940 align:middle line:90%
And I'll see you
in the next one.

140
05:20.940 --> 05:23.107 align:middle line:90%
Meanwhile, I hope this has
been informative for you.

141
05:23.107 --> 05:26.470 align:middle line:90%
And I'd like to thank
you for viewing.