D-Link DFL-1660 User Manual page 487

9.8.5. Specific Error Messages
Since the tunnel L2TP in the above table is above the tunnel VPN-3, a match will trigger before
VPN-3 because of the all-nets remote gateway (all-nets will match any network). Since these two
tunnels use different pre-shared keys, NetDefendOS will generate an "Incorrect pre-shared key"
error message.
The problem is solved if we reorder the list and move VPN-3 above L2TP. The gateway office3gw
will be then matched correctly and VPN-3 will be the tunnel selected by NetDefendOS.
3. Ike_invalid_payload, Ike_invalid_cookie
In this case the IPsec engine in NetDefendOS receives an IPsec IKE packet but is unable to match it
against an existing IKE.
If a VPN tunnel is only established on one side, this can be the resulting error message when traffic
arrives from a tunnel that does not exist. An example would be if, for some reason, the tunnel has
only gone down from the initiator side but the terminator still sees it as up. It then tries to send
packets through the tunnel but when they arrive at the initiator it will drop them since no matching
tunnel can be found.
Simply remove the tunnel from the side that believes it is still up to solve the immediate problem.
An investigation as to why the tunnel only went down from one side is recommended. It could be
that DPD and/or Keep-Alive is only used on one side. Another possible cause could be that even
though it has received a DELETE packet, it has not deleted/removed the tunnel.
4. Payload_Malformed
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 ikesnoop output with normal log messages as ikesnoop does not give
that 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.)
487
Chapter 9. VPN