Firewall characterization test suite

Notes:

In a command window try the following:

  1. telnet panix.com 23 - you should connect and get a response. If this fails, your port 23 (telnet) access is blocked and you have serious problems (you're probably behind a firewall which blocks everything except a few ports, and maybe proxies even those). In this case, you'll probably be limited to the CGI proxies only; httpTunnel might work for you (not in the UAE though) if you have some skills.
  2. telnet www.microsoft.com 80 - you should connect, but there will be no response (if you want to see a response, type GET / HTTP/1.0, enter and then another enter). Note: by default you won't see your characters echoed in MS telnet, unless you enable 'local echo' in the preferences. If you don't connect at all, port 80 is blocked (this is the case in the UAE, KSA).
  3. telnet news.panix.com 119, to check access to Usenet news - you should connect and get a response (but not in the UAE, KSA).
  4. telnet proxy_host proxy_port, to check access to a proxy port - you should connect, but get no response). Elicit a response as described below.
  5. to check a proxy and to see if it's working, how fast it is, whether it is access controlled, or whether it is censoring, connect as above and then type GET http://www.sex.com/, enter and enter again. You should get the www.sex.com main page HTML. Any other result will tell you what the problem is.
  6. to check whether a specific port is blocked or open, you need to know (or make) a listener (server) outside. I recommend netcat for the general case because it builds anywhere, is self contained and can be either client or server. It can replace telnet in all of the above tests and is much quicker to use. It also works for UDP ports.

    You would login to your external account, type nc -vvl -p port, then on the home computer, type nc -vv external_hostname port and see if you connect (it says "open").