Page 186 / 249 Scroll up to view Page 181 - 185
Virtual Private Networking
181
Adding a CA or CRL certificate
Click the
Add new CA or CRL Certificate
tab.
A window similar to the following will be
displayed.
Figure 9-23
Select whether a
Certificate Authority
or
Certificate Revocation List
certificate is to be
uploaded from the
Certificate Type
pull down menu.
Enter the
Certificate Authority's Public Key certificate
or
CRL
file in the
Certificate File
field.
Click the
Browse
button to select the file from the host computer. CA Certificates
have time durations in which they are valid.
Ensure that the certificates uploaded are
valid and that the
Date and Time
has been set correctly on the CyberGuard SG
appliance.
Also ensure that the certificate is in
PEM
or
DER
format.
Click the
Add
button to upload the file.
Page 187 / 249
Virtual Private Networking
182
Adding a local certificate
Click the
Add new Local Certificate
tab.
A window similar to the following will be
displayed.
Figure 9-24
Enter the
Local Public Key certificate
in the
Local Certificate
field.
Click the
Browse
button to select the file from the host computer.
Certificates have time durations in which
they are valid.
Ensure that the certificates uploaded are valid and that the
Date and
Time
settings have been set correctly on the CyberGuard SG appliance.
Also ensure
that the certificate is in
PEM
or
DER
format.
Enter the
Local Private Key certificate
in the
Private Key Certificate
field.
Click the
Browse
button to select the file from the host computer. Ensure the certificate is the
private key for the above public key certificate.
Also ensure that the certificate is in
PEM
or
DER
format.
Enter the passphrase to unlock the private key certificate in the
Private Key Certificate
Passphrase
field.
Click the
Add
button to upload the certificates and passphrase.
Once a CA and local certificate has been uploaded, a window similar to the following will
be displayed.
Page 188 / 249
Virtual Private Networking
183
Figure 9-25
The certificate names will be displayed under the appropriate certificate type.
Clicking
the
Delete
button deletes the certificate from the CyberGuard SG appliance.
Troubleshooting
Symptom:
IPSec is not running and is enabled.
Possible Cause:
The CyberGuard SG appliance has not been assigned a default
gateway.
Solution:
Ensure the CyberGuard SG appliance has a default gateway by
configuring the Internet connection on the Connect to Internet page or assigning a
default gateway on the IP Configuration page.
Symptom:
Tunnel is always down even though IPSec is running and the tunnel is
enabled.
Possible Cause:
The tunnel is using Manual Keying and the encryption and/or
authentication keys are incorrect.
The tunnel is using Manual Keying and the CyberGuard SG appliance's and/or
remote party's keys do not correspond to the Cipher and Hash specified.
Solution:
Configure a correct set of encryption and/or authentication keys.
Select
the appropriate Cipher and Hash that the key have been generated from, or change
the keys used to use the selected Cipher and Hash.
Symptom:
Tunnel is always Negotiating Phase 1.
Possible Cause:
The remote party does not have an Internet IP address (a
No route
to host
message is reported in the system log).
The remote party has IPSec disabled (a
Connection refused
message is reported in
the system log).
Page 189 / 249
Virtual Private Networking
184
The remote party does not have a tunnel configured correctly because:
o
The tunnel has not been configured.
o
The Phase 1 proposals do not match.
o
The secrets do not match.
o
The RSA key signatures have been incorrectly configured.
o
The Distinguished Name of the remote party has not be configured correctly.
o
The Endpoint IDs do not match.
o
The remote IP address or DNS hostname has been incorrectly entered.
o
The certificates do not authenticate correctly against the CA certificate.
Solution:
Ensure that the tunnel settings for the CyberGuard SG appliance and the
remote party are configured correctly.
Also ensure that both have IPSec enabled and
have Internet IP addresses.
Check that the CA has signed the certificates.
Symptom:
Tunnel is always Negotiating Phase 2
Possible Cause:
The Phase 2 proposals set for the CyberGuard SG appliance and
the remote party do not match.
The local and remote subnets do not match.
Solution:
Ensure that the tunnel settings for the CyberGuard SG appliance and the
remote party are configured correctly.
Symptom:
Large packets don't seem to get transmitted
Possible Cause:
The MTU of the IPSec interface is too large.
Solution:
Reduce the MTU of the IPSec interface.
Symptom:
Tunnel goes down after a while
Possible Cause:
The remote
party
has gone down.
The remote
party
has disabled IPSec.
The remote party has disabled the tunnel.
The tunnel on the CyberGuard SG appliance has been configured not to rekey the
tunnel.
The remote party is not rekeying correctly with the CyberGuard SG appliance.
Page 190 / 249
Virtual Private Networking
185
Solution:
Confirm that the remote party has IPSec and the tunnel enabled and has
an Internet IP address.
Ensure that the CyberGuard SG appliance has rekeying
enabled.
If the tunnel still goes down after a period of time, it may be due to the
CyberGuard SG appliance and remote party not recognising the need to renegotiate
the tunnel.
This situation arises when the remote party is configured to accept
incoming tunnel connections (as opposed to initiate tunnel connections) and reboots.
The tunnel has no ability to let the other party know that a tunnel renegotiation is
required.
This is an inherent drawback to the IPSec protocol.
Different vendors have
implemented their own proprietry method to support the ability to detect whether to
renegotiate the tunnel.
Dead peet detection has been implemented based on the
draft produced by Cisco Systems (
draft-ietf-ipsec-dpd-00.txt
).
Unfortunately, unless
the remote party implements this draft, the only method to renegotiate the tunnel is to
reduce the key lifetimes for Phase 1 and Phase 2 for Automatic Keying (IKE).
This
does not occur for Manual Keying.
Symptom:
Dead Peer Detection does not seem to be working
Possible Cause:
The tunnel has Dead Peer Detection disabled.
The remote party does not support Dead Peer Detection according to
draft-ietf-ipsec-
dpd-00.txt
Solution:
Enable Dead Peer Detection support for the tunnel. Unless the remote
party supports
draft-ietf-ipsec-dpd-00.txt
, Dead Peer Detection will not be used.
Symptom:
Tunnels using x.509 certificate authentication do not work
Possible Cause:
The date and time settings on the CyberGuard SG appliance has
not been configured correctly.
The certificates have expired.
The Distinguished Name of the remote party has not be configured correctly on the
CyberGuard SG appliance's tunnel.
The certificates do not authenticate correctly against the CA certificate.
The remote party's settings are incorrect.
Solution:
Confirm that the certificates are valid.
Confirm also that the remote party's
tunnel settings are correct.
Check the Distinguished Name entry in the the
CyberGuard SG appliance's tunnel configuration is correct.
Symptom:
Remote hosts can be accessed using IP address but not by name
Possible cause:
Windows network browsing broadcasts are not being transmitted
through the tunnel.
Solution:
Set up a WINS server and use it to have the remote hosts resolve names
to IP addresses.

Rate

4 / 5 based on 3 votes.

Popular SnapGear Models

Bookmark Our Site

Press Ctrl + D to add this site to your favorites!

Share
Top