Troubleshooting Mobility Client Connections

Technical Note 2137

Last Reviewed 11-May-2007
Applies To
All versions of Mobility
 Printer-friendly version

Summary

Use the following tips to troubleshoot Mobility client connection problems. Often the troubleshooting steps are different when connecting from inside the firewall (e.g., LAN or 802.11) vs. outside the firewall (e.g., GPRS, 1xRTT, remote 802.11 hotspots, home DSL/cable, etc.), so most of the discussions are split into "LAN" and "WAN" sections.

Another good troubleshooting tool is the activity log, a rolling log of mobile device activity in CSV (comma-separated values) format. Just open the file in a spreadsheet program (like Microsoft Excel) to analyze the data.

1. Verify the client's network connection.

   With Mobility in Bypass try to reach other resources, like web sites or your default gateway. It's important to put the client into Bypass when you try this, otherwise it will attempt to send all IP traffic through its VPN tunnel, which doesn't yet have a good connection.

2. Verify the server's IP address.

   On the Configuration tab in the NetMotion Client Properties, verify that the IP address for the server is correct.

   • LAN: The server address is the actual IP address of the server.

   • WAN: The server address is the IP address of your firewall, or the server's NAT address on the firewall.

3. Ping the server from the client.

   When you ping you'll need to put the client into Bypass mode, for the same reason as #1 above. You can also leave the client in its "Connecting..." state and use the -v 255 switch with ping, which sends the ping packets in bypass (e.g., ping 10.1.1.1 -v 255).

   • LAN: Ping works as you would expect it to.

   • WAN: Ping works as you would expect it to, but keep in mind that you're pinging the firewall, not the Mobility server. Many firewalls don't answer pings, so a failed ping may just mean the firewall isn't answering, not that the ping didn't reach it. Also, since your firewall probably won't pass pings through to your Mobility server, ping isn't able to tell you if the entire route to the server is good—it just tells you about the route up to the firewall. Use Tellmes.exe (step #4, below) for more useful information.

4. Test your connectivity through a firewall.

   The Mobility XE client includes a utility that sends a ping over UDP port 5008 to the server and reports whether or not the server is reachable (Mobility uses UDP port 5008 for all of its traffic). In Mobility XE 6.50 and higher you can test connectivity from the client properties:

   1. Open the NetMotion Client Properties (right-click on the Mobility XE icon in the System tray and select Properties).

   2. Click on Diagnostics.

   3. In the Mobility Diagnostics window, click on Connectivity.

   In Mobility 6.01 and earlier, use the command-line utility, Tellmes.exe.

   Notes:

   • LAN: This connectivity test won't tell you any more than ping on a LAN, since it's rare to have an internal firewall blocking ports, but it can still give you clues about the state of the server.

   • WAN: This procedure is extremely useful for testing firewall configuration since it tests the path all the way to the server, unlike ping, which only tests the path up to the firewall.

   If using the utility through a firewall fails it's usually for one of these reasons:

   • There isn't a good network path between the client and the server.

   • The firewall isn't configured correctly to forward UDP port 5008 traffic to the server.

   • The server is multi-homed (it has more than one IP address) and its route table is incorrect.

   One way to tell which reason is causing the problem is to determine if Tellmes traffic is reaching the server: it won't reach the server if the firewall or network is blocking it. On the other hand, the traffic could be reaching the server but the server's response isn't getting back to the client. This condition is often caused by a server with more than one IP address and a route table that doesn't specify which interface to use to reach the clients.

   To determine if the Tellmes utility's traffic is reaching the server, open the server's NetMotion Mobility Event Viewer and turn on Debug events (select Log Settings on the File menu). When you test connectivity from a client you should see several debug events show up in the server's event log (it's best to do this on a server that has no other clients connecting to it, otherwise there will be a lot of other events in the server's log as well):

   • If the connectivity test fails and no events show up in the server's event log, it means the UDP traffic never reached the server. The problem is probably with the firewall or something else blocking UDP traffic.

   • If the connectivity test fails and events do show up in the server's event log, the problem is with the traffic not getting back to the client from the server. Usually this is because of a multi-homed server with a bad route table (for example, two default gateways, or no route defined to the range of client IP addresses).

5. Are you getting an authentication prompt?

   If the Mobility user/password/domain prompt reappears (after you initially try to log in to Windows) it means you're reaching the server. This is an authentication problem (e.g., bad user name), not a connectivity problem.

6. Simplify the connection.

   • LAN: Plug the client into the LAN on the same subnet as the server to get any wireless or routing issues out of the way.

   • WAN: Do your initial testing over the LAN so you get any firewall issues out of the way. Once that works try connecting from outside the firewall.

Related Information

Please comment on this technical note.