D-Link NetDefendOS User Manual page 773

This problem is very similar to the Incorrect pre-shared key problem described above. A possible
reason is that the PSK is of the wrong TYPE on either side (Passphrase or Hex key).
Verify that the same type is being used on both sides of the IPsec tunnel. If one side is using Hex
and the other Passphrase then this is most likely the error message that will be generated.
5. No public key found
This is a very common error message when dealing with tunnels that use certificates for
authentication.
Troubleshooting this error message can be very difficult as the possible cause of the problem can
be quite extensive. Also it is very important to keep in mind that when dealing with certificates
there may be a need to combine the ike -snoop output with normal log messages as ike -snoop
does not give extensive information about certificates, whereas normal logs can provide
important clues as to what the problem could be.
A good suggestion before starting to troubleshoot certificate based tunnels is to first configure it
as a PSK tunnel and then verify that it can be successfully established. Then move on to using
certificates (unless the type of configuration prevents that).
The possible causes of certificate problems can be the following:
• The certificate on either side is not signed by the same CA server.
• A certificate's validity time has expired or it has not yet become valid. The latter can occur if
the clock is set incorrectly on either the CA server or the NetDefend Firewall or they are in
different time zones.
• The NetDefend Firewall is unable to reach the Certificate Revocation List (CRL) on the CA
server in order to verify if the certificate is valid or not. Double-check that the CRL path is valid
in the certificate's properties. (Note that usage of the CRL feature can be turned off.)
Also make sure that there is a DNS client configured for NetDefendOS in order to be able to
correctly resolve the path to the CRL on the CA server.
Note: L2TP with Microsoft Vista
With L2TP, Microsoft Vista tries by default to contact and download the CRL list,
while Microsoft XP does not. This can be turned off in Vista.
• If multiple similar or roaming tunnels exist and there is a need to separate them using ID lists,
a possible cause can be that none of the ID lists match the certificate properties of the
connecting user. Either the user is not authorized or the certificate properties are wrong on
the client or the ID list needs to be updated with this user/information.
• With L2TP, the client certificate is imported into the wrong certificate store on the Windows
client. When the client connects, it is using the wrong certificate.
6. ruleset_drop_packet
If this appears in a log message with IKEv1 roaming clients where tunnel mode is used, it may be
caused by the client's local inner IP address being the same as the client's local outer IP address
for the tunnel. If this is the case, the log message will also have rule=Default_Access_Rule. The
problem is fixed by using config mode to allocate the client IP or using separate routing tables
for the tunnel and the data it carries. This issue is also discussed in Section 9.4.3, "Roaming Clients".
773
Chapter 9: VPN