Management Interface Failure With Vpn; Specific Error Messages - D-Link NetDefend DFL-210 User Manual

Network security firewall ver 2.26.01
Hide thumbs Also See for NetDefend DFL-210:
Table of Contents

Advertisement

9.7.4. Management Interface Failure
with VPN
Once issued, an ICMP ping can then be sent to the NetDefend Firewall from the remote end of the
tunnel. This will cause ikesnoop to output details of the tunnel setup negotiation to the console and
any algorithm proposal list incompatibilities can be seen.
If there are multiple tunnels in a setup or multiple clients on a single tunnel then the output from
verbose option can be overwhelming. It is therefore better to specify that the output comes from a
single tunnel by specifying the IP address of the tunnel's endpoint (this is either the IP of the remote
endpoint or a client's IP address). The command takes the form:
gw-world:/> ikesnoop -on <ip-address> -verbose
Ikesnoop can be turned off with the command:
gw-world:/> ikesnoop -off
For a more detailed discussion of this topic, see Section 9.4.5, "Troubleshooting with ikesnoop".

9.7.4. 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 subnet.
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.7.5. Specific Error Messages

This section will deal with specific error messages that can appear 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.
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 occured.
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 ikesnoop verbose command in the console and get the
tunnel to initiate the tunnel from the remote side. You will be able to then see what proposals the
remote side is sending and then compare the results with your own IKE proposal list. At least
ONE proposal has to match in order for it to pass phase-1. Don't forget that the lifetimes are also
important as will be mentioned in Problem symptom-1. Note: In newer versions it is not possible
397
Chapter 9. VPN

Advertisement

Table of Contents
loading

Table of Contents