Previous Table of Contents Next


Proxy Trouble

You’ll need to treat a proxy server as a server that just happens to be connected to two different networks. As such, you’ll usually need to be able to log into it in order to troubleshoot it.


Presumably, your firewall will have some sort of secure login. Remember, though, what happens when you assume! Make sure your login session is encrypted; if you don’t know, ask your manufacturer. If the login is not encrypted, do not under any circumstances log in from the Internet—it’s a trivial exercise for someone to eavesdrop on your login conversation. All of a sudden, your secure firewall is not so secure anymore, because someone from the outside can now log in to it.

When you log in, you can treat the proxy server just as you would a regular workstation. However, remember that it’s a regular workstation with a double life: a life on your network and a life on the Internet. You’ll do the normal troubleshooting procedures: traceroute, ping, and so on. Furthermore, you can see who’s currently using your proxy server by typing netstat -a or netstat -an (depending upon whether you want numeric output or not).

Pay attention to the LISTENING lines; they’re the proxy services themselves. If one of them goes away, it’s likely that the proxy program associated with it has died. For example, the Socks proxy service listens on socket 1080. If you don’t see something resembling the following, you’ll need to investigate whether the Socks program is still running (use netstat -a):

Active Connections
Proto  Local Address          Foreign Address  State
TCP    proxy.myhost.com:1080  0.0.0.0:*        LISTENING

In this case, the Socks program is definitely running. Whether it’s acting nicely is another story. (For example, maybe the access rule for your network has been accidentally deleted: Although you can connect to the socket, it’s denying you the right to use the proxy. You can only verify this by trying to use it from your network.) You can do a similar trick with other proxies if you know their socket numbers. HTTP is socket 80, FTP is socket 21, and Gopher is socket 70, for example.

Same Name Game: DNS and Firewalls

What about name services? Don’t you need to be able to speed-dial all those servers on the Internet? Here’s the scoop on DNS and firewalls.

Packet-filtering firewalls can be configured to let your DNS servers on the inside perform lookups from the outside. In this case, standard DNS troubleshooting rules apply. The DNS lookup looks something like this:

1.  The client workstation asks the local DNS server to resolve www.jotto.com.
2.  The DNS on the local server can’t find jotto.com; it turns to the outside DNS server.
3.  The outside DNS server returns the IP address to the local DNS server.
4.  The local DNS server returns the IP address to the client workstation.
5.  The client workstation attempts to connect; the packet-filtering firewall grabs the connection and allows it through.

You can determine whether DNS services are working simply by typing ping webname. It’s likely that the ping itself will fail—not all Internet servers allow outsiders to ping them, and your packet-filtering firewall may not be configured to let pings through. However, you should be able to resolve the address. For example, if DNS is working, a ping to an external host might look like this:

C:\WINDOWS>ping www.jotto.com
Pinging www.jotto.com [205.134.224.21] with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

The Destination host unreachable message might not be acceptable, but at least you know that name resolution is working, because www.jotto.com is followed by its IP address, 205.134.224.21. If name resolution were not working, the ping session would look like this:

C:\WINDOWS>ping www.jotto.com
Bad IP address www.jotto.com.
.

This example doesn’t resolve the IP address from the DNS name. The Bad IP address www.jotto.com message from Windows means that the name resolution has failed.

Some proxy servers will allow you to avoid mixing your DNS servers with the outside world’s DNS. This is called proxy DNS, and it works as follows:

1.  The proxy client software tries performing a local lookup on the name (www.jotto.com).
2.  The proxy client software fails with the local lookup, assumes that the name is of a remote site, and asks the proxy server to resolve the name and then proxy the request.
3.  The proxy server resolves the name from an outside DNS server.
4.  The proxy server processes the request and hands the resulting Web page to the client.

Notice that at no time is the IP address passed back to the client. This means you cannot perform the ping trick outlined earlier if you’re using client proxy DNS rather than having your internal DNS servers talk to outside DNS servers. You’ll always get the Bad IP addresshost.outsidecompany.com message.


Not every proxy allows for proxy DNS. Socks version 5, for example, will proxy the DNS for you if you configure the client to do so, but Socks version 4 will not.


Previous Table of Contents Next