
Payloads:
HASH (Hash)
Payload data length : 16 bytes
9.8.5. Management Interface Failure with VPN
If any VPN tunnel is set up and then the management interface no longer operates then it is likely
to be a problem with the management traffic being routed back through the VPN tunnel instead
of the correct interface.
This happens when a route is established in the main routing table which routes any traffic for
all-nets through the VPN tunnel. If the management interface is not reached by the VPN tunnel
then the administrator needs to create a specific route that routes management interface traffic
leaving the NetDefend Firewall back to the management sub-network.
When any VPN tunnel is defined, an all-nets route is automatically defined in the routing table
so the administrator should always set up a specific route for the management interface to be
correctly routed.
9.8.6. Specific Error Messages
This section will deal with specific error messages that can appear in log event messages with
VPN and what they indicate. The messages discussed are:
1. Could not find acceptable proposal / no proposal chosen.
2. Incorrect pre-shared key.
3. Ike_invalid_payload, Ike_invalid_cookie.
4. Payload_Malformed.
5. No public key found.
6. ruleset_drop_packet.
1. Could not find acceptable proposal / no proposal chosen
This is the most common IPsec related error message. It means that depending on which side
initiates tunnel setup, the negotiations in either the IKE or the IPSec phase of setup failed since
they were unable to find a matching proposal that both sides could agree on.
Troubleshooting this error message can be involved since the reasons for this message can be
multiple depending on where in the negotiation it occurred.
•
If the negotiation fails during phase-1 – IKE
The IKE proposal list does not match. Double check that the IKE proposal list matches that of
the remote side. A good idea is to use the
ike -snoop -verbose
CLI command and have
initiation of the tunnel by the remote peer. It can then be seen what proposals the remote
side is sending and then compare the results with the local IKE proposal list. At least ONE
proposal has to match in order for it to pass phase-1. Remember that the lifetimes are also
important, as will be mentioned in Problem symptom-1.
•
If the negotiation fails during phase-2 – IPsec
The IPsec proposal list does not match. Double check that the local IPsec proposal list
matches that of the remote peer. The same method described above of using
ike -snoop
can
be used when the remote side initiates the tunnel, comparing it against the local 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 one side need to be the remote network on the other side and vice versa.
Chapter 9: VPN
771
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 ...