Filter
Top Products
tunnels use different pre-shared keys, you will receive 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 you are using the same type on both sides of the IPsec tunnel. If one side is using Hex
and the other Passphrase, this is most likely the error message that you will receive.
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 you
may need to combine the ikesnoop logs with normal logs as ikesnoop does not give that much
information about certificates, while normal logs can provide important clues as to what the problem
could be. A good suggestion before you start to troubleshoot certificate based tunnels is to first
configure it as a PSK tunnel and then verify that it can successfully establish, then move on to using
Certificates. (Unless the configuration type prohibits that).
The possible causes are as follows:
• The certificate on either side is not signed by the same CA server.
• The certificate's validity time has expired or it has not yet started to be valid. The latter can
happen 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. (Using the CRL feature could be turned off.) Make sure also that
there is a DNS client configured in NetDefendOS in order for it to be able to correctly resolve
the path to the CRL.
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 option can be turned off in Vista.
9.7.5. Specific Error Messages Chapter 9. VPN
441