Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to troubleshoot a custom application that lives inside of a firewall on an enterprise network running Windows 2003 server. Our application uses PHP/cURL to send XML data to a publicly hosted website. By default, one can't uses a browser on this server; however, an earlier iteration of the application was able to go outbound on port 80 (in spite of the browser lock down).

I need a simple way of determining whether I can reach a particular destination via port 80 or port 443 (e.g.

I would like to verify this before I work with the customer on changing their firewall/web filtering setup.

share|improve this question
up vote 0 down vote accepted

You need a system at that address running a service on that port, and that system needs to not have incoming traffic blocked. If that is true, then you need to try to communicate somehow on that port to the service listening. That is the only 100% reliable way to know for sure without knowing the exact firewall configuration on both sides.

However, if the only problem you are having is that you can't use a browser, and you are trying to test from Windows Server 2003, you can issue a manual HTTP request using telnet. Try this in a command prompt:

telnet 80

Then, press ENTER once, and then type exactly (you won't be able to see what you type):

GET / HTTP/1.1

Then press ENTER.

If a webserver is listening on that port and is reachable, you'll get a bunch of HTML back. If not, the connection will time out.

share|improve this answer
I know for sure that the destination server is listening and available... The manual HTTP request timed out, so this appears to be either a web filtering or firewall issue – Kendor Jun 6 '12 at 13:31

Firebind is a cloud-based network path validation tool that uses a java applet client to send packets over any TCP or UDP port between your machine and the Firebind server. This provides testing in the outbound (private network to Internet) direction.

You can pick any of the 65535 TCP or UDP ports (or even all of them if you'd like) to test. Firebind dynamically opens up ports on the server-side to "listen" for the test traffic from the java applet client. If the test packets reach the server intact, and then are echoed successfully back to the client unchanged, then the port test will be successful. If there is any sort of firewall blocking a given port, Firebind will report a failure. For the TCP protocol it will even tell you how it was blocked (such as a TCP DROP/timeout or a TCP RESET/reject.)

share|improve this answer
See also :… – Marc MAURICE Jul 30 '13 at 11:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .