Tunnel Server and Client Configuration Checks

118 of clients fail to connect to the tunnel, first check the tunnel server software configuration. The problem areas are incorrect dynamic address ranges, mistyped tunnel name information, or improper key extraction. To check the validity of the dynamic address ranges, simply ensure that the list of Ranges on the Dynamic Address tab in the Configuration option under the Tunnels menu matches those available to the server. The available dynamic address range is a field in the tunnel properties window. Next, verify that the tunnel name matches what the end user has typed. Tunnel names are case-sensitive, so youll need to have the user spell out exactly what is typed. If youve ever had to troubleshoot a usernamepassword problem, this is old hat. Last, re-extract the key files and distribute them to the end user. Additionally, IP forwarding must be enabled on the tunnel server, or the tunnel will not function, period. On Digital Unix, type the following commands: iprsetup -s rcmgr set ROUTER yes Note that these commands are case-sensitive. You must have root access to execute the commands. With Windows NT, IP forwarding is enabled from the TCPIP Protocol Properties in the Networking control panel. Simply click the checkbox labeled Enable IP Forwarding. If all these areas are correct, the difficulty may be an end user problem. Users fall into two camps for the most part: I dont know anything about this or I know enough about this to be a real pain in the.... Of course, your job as network administrator is to guide both camps with a gentle, knowledgeable hand. Have them again repeat the exact configuration, taking each field separately and slowly. IP addresses are often miskeyed, as are server names and passwords. Ensure that if there is an interposing firewall, the user has port 3265 in the firewall port field. Additionally, check that the AltaVista Tunnel pseudo-adapter is installed in the Networking control panel. In our testing, we experienced a scenario where the user didnt reboot the machine after installing the tunnel client software. This is, of course, imperative. If all looks clean, then there could be configuration problems on the local network or the Internet gateway.

7.5.2 Local Network and Internet Gateway Configuration Checks

The easiest way to begin checking the local network and Internet gateway configuration is to have the user attempt to telnet to the tunnel servers network firewall at port 3265. To do this, have the user go to the Start Menu on Windows 95, choose the Run menu option, and type: telnet your_firewall 3265 The user should be able to connect to the firewall at that port. However, the firewall will display an error message when keystrokes are entered. The firewall will immediately issue a connection failed message if this port is not enabled. This port will obviously have to be enabled for tunnel traffic to commence. Also, this port should be set up as a generic relay. This will forward all traffic for port 3265 to the tunnel servers pseudo-adapter. If the user can connect to the tunnel, but subsequently gets disconnected, this is symptomatic of a misconfigured firewall port. 119 If the tunnel client can connect to and authorize the tunnel server, but cannot reach other machines on the internal network, there could be two problems: either IP forwarding is not enabled on the tunnel server, or the tunnel is in an infinite loop. Such a loop can occur between the virtual IP address and physical IP address of the tunnel server. The loop indicates a misconfiguration in the Routing tab of the tunnel server configuration. To diagnose which problem exists, have the user ping the tunnel servers pseudo-adapter address. To do this, the user must open a DOS window and type: ping virtual_IP where virtual_IP is the pseudo-adapter address. If this ping is successful, ping the tunnel servers real IP address. If this ping fails, the tunnel is in an infinite loop. If the first ping fails and the second is successful, the IP forwarding is not properly enabled on the tunnel server. If both pings fail, the client machine cannot reach the server at all. This could be a firewall or router issue on the server side of the connection and should be investigated further. If all these tests pass, and IP forwarding is properly enabled on the server, the user should attempt to traceroute to a machine on the local network. The command in Windows 95 is: tracert other_machine or, from a Unix command line: traceroute other_machine where other_machine refers to the domain name of the internal machine to which we want to trace traffic. If this is successful, it shows that the client machine is sending packets through the servers tunnel pseudo-adapter and to the internal machine on the servers network. If it fails, routing is misconfigured on the tunnel server. Recheck the routes on the Routing tab in the Tunnel Configuration menu. Next, do the same procedure from the machine internal to the tunnel servers network. Trace back to the clients unique domain name. If this checks out, and there is still a problem, it resides in some other application or service. If this test fails, routing for the internal network is improperly configured. Refer to the examples in Chapter 6 for internal network configuration scenarios. To support these tests, you may also check the tunnel servers ReadWrite counters in the Tunnel Manager application. These counters will tell you how many bytes were read and written to the tunnel by a particular tunnel client. It may take some time to educate both system administrators and end users to this new twist in the Internet troubleshooting process, but with the points presented here and simple networking common sense, you should have your AltaVista Tunnel up in no time.