7
IPsec VPN
149
Consider
the
first
part:
172.22.53.18:500
<
‐
172.22.53.23:500
Indicates
that
an
initial
request
to
set
up
a
security
association
was
made
and
originates
from
remote
IPv4
address
172.22.53.23
,
port
500
,
which
will
be
the
remote
tunnel
endpoint.
This
was
received
at
local
IPv4
address
172.22.53.18
,
port
500
on
the
local
security
gateway
and
this
will
be
the
local
tunnel
endpoint.
The
nature
of
this
request
is
described
next:
IKE_SA_INIT
request
0
[
SA
KE
No
N(NATD_S_IP)
N(NATD_D_IP)
]
It
is
a
security
association
(SA)
initialization
and
the
various
abbreviations
describe
the
details:
•
KE
‐
Key
Exchange
•
No
‐
NONCE
•
N
‐
Notify
The
notification
payloads
in
this
case
are
NATD_S_IP
and
NATD_D_IP
.
The
second
part
of
the
output
shows
the
local
security
gateway
sending
the
IKE
response
back
to
IPv4
address
172.22.53.23
:
172.22.53.18:500
‐
>
172.22.53.23:500
The
third
part
of
the
output
(
IKE_AUTH
request
1
)
is
a
request
from
the
remote
tunnel
endpoint
172.22.53.23
to
try
and
agree
algorithms:
IDi
AUTH
SA
TSi
TSr
N(INIT_CONTACT)
N(ESP_TFC_PAD_N)
N
(NON_FIRST_FRAG)
The
actual
algorithms
in
the
proposal
lists
sent
by
each
tunnel
peer
are
not
shown
in
this
summary
version
of
the
ike
command.
However,
the
sequence
of
steps
leading
to
success
or
failure
are
shown.
Complete
ike
command
options
and
abbreviation
descriptions
can
be
found
in
the
SEG
‐
100
Command
Line
Interface
Reference
.
Management interface failure with VPN
If
a
VPN
tunnel
is
set
up
and
then
the
SEG
management
interface
stops
operating,
it
is
likely
a
problem
with
the
management
traffic
being
routed
back
through
the
VPN
tunnel
instead
of
the
correct
interface.
This
happens
when
a
route
is
established
in
the
main
routing
table
which
routes
any
traffic
for
all
‐
nets
through
the
VPN
tunnel.
If
the
management
interface
is
not
reached
by
the
VPN
tunnel
then
the
administrator
needs
to
create
a
specific
route
that
routes
management
interface
traffic
leaving
the
SEG
back
to
the
management
sub
‐
network.