7
IPsec VPN
144
•
Try
and
avoid
duplication
of
IP
addresses
between
the
remote
network
being
accessed
by
a
client
and
the
internal
network
to
which
a
roaming
client
belongs.
If
a
roaming
client
becomes
temporarily
part
of
a
network
such
as
a
Wi
‐
Fi
network
at
an
airport,
the
client
will
get
an
IP
address
from
the
Wi
‐
Fi
network's
DHCP
server.
If
that
IP
also
belongs
to
the
network
behind
the
SEG
accessible
through
a
tunnel,
then
Windows
will
still
continue
to
assume
that
the
IP
address
is
to
be
found
on
the
client's
local
network.
Windows
therefore
will
not
correctly
route
packets
bound
for
the
remote
network
through
the
tunnel
but
instead
route
them
to
the
local
network.
The
solution
to
this
problem
of
local/remote
IP
address
duplication
is
to
create
a
new
route
in
the
client's
Windows
routing
table
that
explicitly
routes
the
IP
address
to
the
tunnel.
For
example,
suppose
192.168.99.2
is
the
server
to
be
reached,
192.168.0.0/24
is
the
remote
network
and
192.168.99.2
is
assigned
by
L2TP
or
PPTP
to
the
Windows
computer.
The
Windows
command
line
to
add
a
route
would
be:
C:\>
route
add
192.168.0.2
mask
255.255.255.255
192.168.99.2
•
Verify
that
the
correct
tunnel
is
being
selected.
When
an
external
client
connects,
the
SEG
makes
a
decision
about
which
IPsec
tunnel
object
to
use
by
choosing
the
tunnel
that
has
the
parameters
that
most
closely
match
the
incoming
connection.
However,
the
tunnel
object
selected
in
the
initial
exchange
between
client
and
the
SEG
may
have
to
change
because
a
mismatch
is
discovered
in
a
later
phase.
This
can
result,
for
example,
in
a
situation
where
the
proposal
list
matches
one
IPsec
tunnel
object
but
authentication
matches
another
tunnel
object.
The
administrator
should
be
aware
this
can
happen
so
that
unexpected
behavior
can
be
understood.
This
topic
is
discussed
with
more
depth
in
IPsec
with
the
SEG
on
page
132
.
Troubleshooting certificate problems
If
certificates
have
been
used
in
a
VPN
solution
then
the
following
should
be
looked
at
as
a
source
of
potential
problems:
•
Check
that
the
correct
certificates
have
been
used
for
the
correct
purposes.
•
Check
that
the
certificate
.cer
and
.key
files
have
the
same
filename.
For
example,
my_cert.key
and
my_cert.cer
.
•
Check
that
the
certificates
have
not
expired.
Certificates
have
a
specific
lifetime
and
when
this
expires
they
cannot
be
used
and
new
certificates
must
be
issued.
•
Check
that
the
SEG
date
and
time
are
set
correctly.
If
the
system
time
and
date
are
wrong,
certificates
can
appear
as
expired
when
they
are
not.
•
Consider
time
‐
zone
issues
with
newly
generated
certificates.
The
SEG’s
time
zone
may
not
be
the
same
as
the
CA
server’s
time
zone
and
the
certificate
may
not
yet
be
valid
in
the
local
zone.
•
Disable
CRL
(revocation
list)
checking
to
see
if
CA
server
access
could
be
the
problem.
CA
server
issues
are
discussed
further
in
CA
server
access
on
page
140
.
•
Use
the
ike
CLI
command
to
clear
the
certificate
cache:
Device:/>
ike
‐
cert
‐
flush
