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”
Chapter 9: VPN
773
Summary of Contents for NetDefendOS
Page 30: ...Figure 1 3 Packet Flow Schematic Part III Chapter 1 NetDefendOS Overview 30 ...
Page 32: ...Chapter 1 NetDefendOS Overview 32 ...
Page 144: ...Chapter 2 Management and Maintenance 144 ...
Page 284: ...Chapter 3 Fundamentals 284 ...
Page 392: ...Chapter 4 Routing 392 ...
Page 419: ... Host 2001 DB8 1 MAC 00 90 12 13 14 15 5 Click OK Chapter 5 DHCP Services 419 ...
Page 420: ...Chapter 5 DHCP Services 420 ...
Page 573: ...Chapter 6 Security Mechanisms 573 ...
Page 607: ...Chapter 7 Address Translation 607 ...
Page 666: ...Chapter 8 User Authentication 666 ...
Page 775: ...Chapter 9 VPN 775 ...
Page 819: ...Chapter 10 Traffic Management 819 ...
Page 842: ...Chapter 11 High Availability 842 ...
Page 866: ...Default Enabled Chapter 13 Advanced Settings 866 ...
Page 879: ...Chapter 13 Advanced Settings 879 ...