D-Link DFL-260E User Manual for DFL-260E - Page 477
VPN Troubleshooting, all-nets, Incorrect Pre-shared, IPsec Before Rules, vpn.company.com
View all D-Link DFL-260E manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 477 highlights
9.8. VPN Troubleshooting Chapter 9. VPN 9.8. VPN Troubleshooting This section deals with how to troubleshoot the common problems that are found with VPN. 9.8.1. General Troubleshooting In all types of VPNs some basic troubleshooting checks can be made: • Check that all IP addresses have been specified correctly. • Check that all pre-shared keys and usernames/passwords are correctly entered. • Use ICMP Ping to confirm that the tunnel is working. With roaming clients this is best done by Pinging the internal IP address of the local network interface on the NetDefend Firewall from a client (in LAN to LAN setups pinging could be done in any direction). If NetDefendOS is to respond to a Ping then the following rule must exist in the IP rule set: Action Allow Src Interface vpn_tunnel Src Network all-nets Dest Interface core Dest Network all-nets Service ICMP • Ensure that another IPsec Tunnel definition is not preventing the correct definition being reached. The tunnel list is scanned from top to bottom by NetDefendOS and a tunnel in a higher position with the Remote Network set to all-nets and the Remote Endpoint set to none could prevent the correct tunnel being reached. A symptom of this is often an Incorrect Pre-shared Key message. • Try and avoid duplication of IP addresses between the remote network being accessed by a client and the internal network to which a roaming client belongs. If a roaming client becomes temporarily part of a network such as a Wi-Fi network at an airport, the client will get an IP address from the Wi-Fi network's DHCP server. If that IP also belongs to the network behind the NetDefend Firewall accessible through a tunnel, then Windows will still continue to assume that the IP address is to be found on the client's local network. Windows therefore will not correctly route packets bound for the remote network through the tunnel but instead route them to the local network. The solution to this problem of local/remote IP address duplication is to create a new route in the client's Windows routing table that explicitly routes the IP address to the tunnel. • If roaming client user authentication is not asking the users for their username/password then ensure that the following advanced settings are enabled: • IPsec Before Rules for pure IPsec roaming clients. • L2TP Before Rules for L2TP roaming clients. • PPTP Before Rules for PPTP roaming clients. These settings should be enabled by default and they ensure that user authentication traffic between NetDefendOS and the client can bypass the IP rule set. If the appropriate setting is not enabled then an explicit rule needs to be added to the IP rule set to allow the authentication traffic to pass between roaming clients and NetDefendOS. This rule will have a destination interface of core (which means NetDefendOS itself). • If the remote endpoint is specified as a URL, make sure that the URL string is preceded by the prefix dns:. If, for example, the tunnel remote endpoint is to be specified as vpn.company.com, this should be specified as dns:vpn.company.com. 477