D-Link NetDefend DFL-210 User Manual page 398

9.7.5. Specific Error Messages
to set the lifetime in KB for the IKE Phase, only seconds.
• If the negotiation fails during phase-2 – IPsec
The IPsec proposal list does not match. Double check that the IPsec proposal list matches that of
the remote side. You can use the same method described above of using ikesnoop from when the
remote side initates the tunnel and compare it against your own proposal list. What is "extra" in
the IPsec phase is that the networks are negotiated here, so even if the IPsec proposal list seem
to match the problem may be with mismatching networks. The Local Network(s) on your side
needs to be the Remote Network on the other side and vice versa. Remember that multiple
networks will generate multiple IPsec SA's, one SA per network (or host if you use that option).
The defined network size is also important in that it must have exactly the same size on both
sides, as will be mentioned again later in the symptom section.
There are also some settings on the IPsec tunnel's IKE tab that can be involved in a no-proposal
chosen issue. Such as Main or Aggressive mode, DH Group (for the IKE phase) and PFS (for
IPsec phase).
2. Incorrect pre-shared key
A problem with the pre-shared key on either side has caused the tunnel negotiation to fail. This is
perhaps the easiest of all the error messages to troubleshoot since it can be only one thing, and that
is incorrect pre-shared key. Double-check that the pre-shared key is of the same type (Passphrase or
Hex-key) and correctly added on both sides of the tunnel.
Another reason for why NetDefendOS detects that the pre-shared key is incorrect could be because
the wrong tunnel is triggering during tunnel negotiations. IPsec tunnels are processed from the top
to the bottom of the NetDefendOS tunnel list and are initially matched against the remote gateway.
An example is if there is a roaming tunnel that uses all-nets as its remote gateway. This tunnel will
trigger before your defined tunnel if it is above it in the tunnel list.
For example, consider the following IPsec tunnel definitions:
Name
VPN-1
VPN-2
L2TP
VPN-3
Since the tunnel L2TP in the above table is above the tunnel VPN-3, it will trigger a match 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, 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.
Local Network Remote Network
lannet
lannet
ip_wan
lannet
398
Remote Gateway
office1net
office2net
all-nets
office3net
Chapter 9. VPN
office1gw
office2gw
all-nets
office3gw