Get started with troubleshooting VPN

Vie this information to begin finding and correcting your VPN connection problems.

There are several ways to begin analyzing VPN problems:

Always make sure that you have applied the latest Program Temporary Fixes (PTFs).
Ensure that you meet the minimum VPN setup requirements.
Review any error messages that are found in the Error Information window or in the VPN server job logs for both the local and the remote systems. In fact, when you are troubleshooting VPN connection problems it is often necessary to look at both ends of the connection. Further, you need to take into account that there are four addresses you must check: The local and remote connection endpoints, which are the addresses where IPSec is applied to the IP packets, and the local and remote data endpoints, which are the source and destination addresses of the IP packets.
If the error messages you find do not provide enough information to solve the problem, check the IP filter journal.
The communication trace on the system offers you a another place to find general information about whether the local system receives or sends connection requests.
The Trace TCP Application (TRCTCPAPP) command provides yet another way to isolate problems. Typically, IBM^® Service uses TRCTCPAPP to obtain trace output in order to analyze connection problems.

Other things to check

If an error occurs after you set up a connection, and you are not sure where in the network the error occurred, try reducing the complexity of your environment. For example, instead of investigating all parts of a VPN connection at one time, start with the IP connection itself. The following list gives you some basic guidelines on how to start VPN problem analysis, from the simplest IP connection to the more complex VPN connection:

Start with an IP configuration between the local and remote host. Remove any IP filters on the interface that both the local and remote system use for communicating. Can you PING from the local to the remote host?
Note: Remember to prompt on the PING command; enter the remote system address and use PF10 for additional parameters, then enter the local IP address. This is particularly important when you have multiple physical or logical interfaces. It ensures that the right addresses are placed in the PING packets.

If you answer yes, then proceed to step 2. If you answer no, then check your IP configuration, interface status, and routing entries. If the configuration is correct, use a communication trace to check, for example, that a PING request leaves the system. If you send a PING request but you receive no response, the problem is most likely the network or remote system.

Note: There may be intermediate routers or firewall that do IP packet filtering and may be filtering the PING packets. PING is typically based on the ICMP protocol. If the PING is successful, you know you have connectivity. If the PING is unsuccessful, you only know the PING failed. You may want to try other IP protocols between the two systems, such as Telnet or FTP to verify connectivity.
Check the filter rules for VPN and ensure that they are activated. Does filtering start successfully? If you answer yes, then proceed to step 3. If you answer no, then check for error messages in the Packet Rules window in iSeries™ Navigator. Ensure that the filter rules do not specify Network Address Translation (NAT) for any VPN traffic.
Start your VPN connection. Does the connection start successfully? If you answer yes, then proceed to step 4. If you answer no, then check the QTOVMAN job log, the QTOKVPNIKE job logs for errors. When you use VPN, your Internet Service Provider (ISP) and every security gateway in your network must support the Authentication Header (AH) and Encapsulated Security Payload (ESP) protocols. Whether you choose to use AH or ESP depends on the proposals you define for your VPN connection.
Are you able to activate a user session over the VPN connection? If you answer yes, then the VPN connection works as required. If you answer no, then check the packet rules and the VPN dynamic-key groups and connections for filter definitions that do not allow the user traffic you want.