Remember that multiple networks will generate multiple IPsec SAs, one SA per network (or
host if that option is used). The defined network size is also important in that it must be
exactly the same size on both sides, as will be mentioned again later in the symptoms
section.
There are also some settings on the IPsec tunnel's IKE tab that can be involved in a
no-proposal chosen issue. For example, PFS (for IPsec phase) or DH Group (for the IKE 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 the intended tunnel if it is placed above it in the
NetDefendOS tunnel list.
For example, consider the following IPsec tunnel definitions:
Name
Local Network
Remote Network
Remote Gateway
VPN-1
lannet
office1net
office1gw
VPN-2
lannet
office2net
office2gw
L2TP
ip_wan
all-nets
all-nets
VPN-3
lannet
office3net
office3gw
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
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
Chapter 9: VPN
772
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 ...