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
To Next Page
Loading...
