Virtual Private Networking
223
• 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).
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: The tunnel appears to be up and I can ping across it, but HTTP, FTP,
SSH, telnet, etc. don’t work
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.
To Next Page
Loading...
Need help?
General
