7
IPsec VPN
134
Now
consider
the
following
sequence:
1. A
client
with
IPv4
address
177.22.0.47
initiates
an
IPsec
negotiation
with
an
IKE_INIT
message.
2. Assuming
that
the
client’s
proposal
list
can
match
either
tunnel,
the
IPsec
tunnel
object
B
is
chosen
for
the
connection
because
its
remote
endpoint
is
a
narrower
match
to
the
client's
IP
address.
3. The
IKE_AUTH
phase
now
begins
and
the
SEG
finds
out
that
the
client
wants
to
use
PSK
for
authentication
with
an
ID
of
.
4. Tunnel
B
no
longer
matches
the
client’s
authentication
requirements.
The
SEG
will
therefore
search
the
IPsec
tunnel
object
list
looking
for
another
tunnel
that
can
match
and
finds
tunnel
definition
A
.
The
end
result
of
these
steps
is
that
an
IPsec
tunnel
is
established
but
it
uses
the
IKA
SA
established
with
tunnel
B
and
the
authentication
established
with
tunnel
A
.
This
may
not
be
the
intended
result
so
the
administrator
should
take
care
when
defining
IPsec
tunnel
objects.
IPsec rekeying
The
SEG
supports
IPsec
rekeying
.
This
means
that
a
rekey
of
the
IKE
and
IPsec
Security
Associations
(SAs)
will
be
initiated
based
upon
the
configured
values
in
the
proposal
lists
for
IKE
and
IPsec.
The
lifetimes
of
the
IKA
SAs
and
IPsec
SAs
can
be
limited
based
on
the
time
since
they
were
created.
The
SEG
will
respond
to
re
‐
keying
requests
initiated
by
the
MS
as
described
by
the
IKEv2
specification.
Important:
The
administrator
should
be
aware
of
the
effect
of
uploading
a
new
SEG
configuration
to
an
security
gateway
that
is
supporting
live
IPsec
tunnels.
If
any
changes
to
the
IPsec
configuration
are
made
as
part
of
a
new
SEG
configuration,
then
any
live
IPsec
tunnel
connections
will
be
terminated
and
must
be
re
‐
established.
This
next
section
covers
the
steps
for
IPsec
tunnel
setup
with
the
SEG
in
more
detail.