2. How to Troubleshoot Application Connectivity Problems
Sometimes, you might be
able to access the network with some applications but not others. For
example, you might be able to download your e-mail but not access Web
servers. Or, you might be able to view pages on a remote Web server but
not connect to the computer with Remote Desktop.
Several issues might cause these symptoms (in rough order of likelihood):
The remote service is not running. For example, Remote Desktop might not be enabled on the remote computer.
The remote server has a firewall configured that is blocking that application's communications from your client computer.
A firewall between the client and server computer is blocking that application's communications.
Windows Firewall on the local computer might be configured to block the application's traffic.
remote service has been configured to use a non-default port number.
For example, Web servers typically use TCP port 80, but some
administrators might configure TCP port 81 or a different port.
To troubleshoot an application connectivity problem, follow these steps:
Before you begin troubleshooting
application connectivity, first verify that you do not have a name
resolution problem. To do this, open a command prompt and run the
command Nslookup servername.
If Nslookup does not display an answer similar to the following
example, you have a name resolution problem.
Addresses: 10.46.232.182, 10.46.130.117
Identify the port number used by the application. Table 1
lists port numbers for common applications. If you are not sure which
port numbers your application uses, consult the application's manual or
contact the technical support team. Alternatively, you can use a
protocol analyzer, such as Network Monitor, to examine network traffic
to determine the port numbers used.
Table 1. Default Port Assignments for Common Services and Tasks
|SERVICE NAME OR TASK||UDP||TCP|
|Web servers, HTTP, and Internet Information Services (IIS)|| ||80|
|HTTP- Secure Sockets Layer (SSL)|| ||443|
|DNS client-to-server lookup (varies)||53||53|
|DHCP client|| ||67|
|File and printer sharing||137||139, 445|
|Internet Relay Chat (IRC)|| ||6667|
|Microsoft Office Outlook (see POP3, IMAP, and SMTP for ports)|| || |
|Internet Mail Access Protocol (IMAP)|| ||143|
|IMAP (SSL)|| ||993|
|LDAP (SSL)|| ||636|
|Message Transfer Agent (MTA) – X.400 over TCP/IP|| ||102|
|POP3 (SSL)|| ||995|
|RPC endpoint mapper|| ||135|
|Network News Transfer Protocol (NNTP)|| ||119|
|NNTP (SSL)|| ||563|
|POP3 (SSL)|| ||995|
|SNMP Trap||162|| |
|SQL Server|| ||1433|
|Terminal Server and Remote Desktop|| ||3389|
|Point-to-Point Tunneling Protocol (PPTP) || ||1723|
|Joining an AD DS domain || || |
After identifying the port number, the first step in troubleshooting the application
connectivity problem is to determine whether communications are
successful using that port. If it is a TCP port, you can use PortQry,
Test TCP, or Telnet. Of those three tools, Telnet is the least flexible,
but it is the only tool included with Windows (but note that it is not
installed by default).
To test a TCP port with Telnet, run the following command.
Telnet hostname_or_address TCP_port
For example, to determine whether you can connect to the Web server at www.microsoft.com (which uses port 80), you would run the following command.
Telnet www.microsoft.com 80
If the command prompt
clears or if you receive text from the remote service, you have
successfully established a connection. Close the command prompt to
cancel Telnet. This indicates that you can connect to the server;
therefore, the server application is listening for incoming connections
and no firewall is blocking your traffic. Instead of troubleshooting the problem as a connectivity issue, you should consider application-level issues, including:
View the server's Security Event Log or the application's log to
determine whether it is rejecting your client connections because of
Failed service Restart the server. Test whether other client computers can connect to the server.
Invalid client software Verify that the client software running on your computer is the correct version and is configured properly.
If Telnet displays "Could not open connection to the host," this indicates an application connectivity issue, such as a misconfigured firewall. Follow these steps to continue troubleshooting the problem:
possible, verify that the server is online. If the server is online,
attempt to connect to a different service running on the same server.
For example, if you are attempting to connect to a Web server and you
know that the server has file sharing enabled, attempt to connect to a
shared folder. If you can connect to a different service, the problem is
almost certainly a firewall configuration problem on the server.
to connect from different client computers on the same and different
subnets. If you can connect from a client computer on the same subnet,
you might have an application configuration problem on the client
computer. If you can connect from a client computer on a different
subnet but not from the same subnet, a firewall on the network or on the
server might be filtering traffic from your client network.
possible, connect a client computer to the same subnet as the server.
If you can connect from the same subnet but not from different subnets, a
router-based firewall is blocking traffic. If you cannot connect from
the same subnet, the server has a firewall that is blocking traffic.
Alternatively, the server application might not be running or might be
configured to use a different port.
on to the server and use Telnet to attempt to connect to the server
application port. If you can connect to the server from the server but
not from other computers, the server definitely has firewall software
configured. Add an exception for the application to the firewall
software. If you cannot connect to the server application from the
server, the application is not listening for connections or is
configured to listen for incoming connections on a different port. Refer
to the application
documentation for information on how to start and configure the
application. If the server is running Windows, you can use Netstat to
identify on which ports the server is listening for incoming