7
IPsec VPN
138
The
setup
steps
are
as
follows:
1. Connect
to
the
management
interface
for
the
SEG
at
one
end
of
the
tunnel.
2. Upload
the
Root
Certificate
and
Host
Certificate
into
the
SEG
using
SSH.
The
root
certificate
needs
to
have
2
parts
added:
a
certificate
file
and
a
private
key
file.
The
gateway
certificate
needs
just
the
certificate
file
added.
Associate
the
certificates
with
a
LocalID
.
3. Set
up
the
IPsecTunnel
object
in
the
same
way
as
for
pre
‐
shared
keys
with
the
following
differences:
•
Set
LocalAuthMethod
to
Certificate
(by
default,
RemoteAuthMethod
assumes
the
same
value).
•
The
LocalID
must
match
the
value
associated
with
at
least
one
certificate
in
the
system.
4. Connect
to
the
management
interface
for
the
SEG
at
the
other
side
of
the
tunnel
and
repeat
the
above
steps
with
a
different
set
of
certificates.
Note:
The
SEG
date
and
time
should
be
set
correctly
since
certificates
have
an
expiration
date
and
time.
Review
CA
server
access
on
page
140
,
which
describes
important
considerations
for
certificate
validation.
NAT traversal
Both
IKE
and
IPsec
protocols
present
a
problem
in
the
functioning
of
NAT.
Both
protocols
were
not
designed
to
work
through
NATs
and
because
of
this,
a
technique
called
NAT
traversal
(NAT
‐
T)
has
evolved.
This
is
an
add
‐
on
to
the
IKE
and
IPsec
protocols
and
it
allows
them
to
function
while
undergoing
NAT.
The
SEG
supports
the
following
standards
for
NAT
traversal
with
IKE:
•
RFC
4306
for
IKEv2.
NAT
traversal
is
divided
into
two
parts:
•
Additions
to
IKE
that
lets
IPsec
peers
tell
each
other
that
they
support
NAT
traversal
and
the
specific
versions
supported.
•
Changes
to
the
ESP
encapsulation.
If
NAT
traversal
is
used,
ESP
is
encapsulated
in
UDP,
which
allows
for
more
flexible
NATing.
NAT
traversal
is
used
only
if
both
ends
have
support
for
it.
For
this
purpose,
NAT
traversal
aware
VPNs
send
out
a
special
“vendor
ID”
to
tell
the
other
end
of
the
tunnel
that
it
understands
NAT
traversal,
and
which
specific
versions
of
the
draft
it
supports.
