Firebind is the world's only web-based Internet path scanner. It provides a straightforward way to verify whether your application will be able to successfully communicate to its respective server via your Internet connection. Web browsing with applications such as Internet Explorer or FireFox use the HTTP protocol over TCP port 80. This is the most popular port used on the Internet, however, it is just one of tens of thousands of TCP ports that are used by various applications to talk to a server.

Others include AOL Instant Messenger (TCP port 5190), Slingbox (TCP port 5001), Lotus Notes (TCP port 1352), and Remote Desktop (TCP port 3389). In order to prevent certain applications from being used, an Internet provider, whether it be a home broadband (Cable/DSL/Fiber) provider, coffee shop, hotel, airport, or corporation can block a given port or range of ports by creating a rule in their firewall. When you try to run your application, the firewall rule blocks the port to prevent you from reaching your server, but most applications aren't able to provide feedback indicating why it is failing to work, leaving the user to wonder whether perhaps the server is down or maybe their client machine has some sort of problem.

Since virtually all firewalls will leave TCP port 80 (HTTP) open, Firebind uses that port to talk to its server and create a "listener" on the port the user is interested in. For example, if you are trying to test whether port 5190 is open for AOL Instant Messenger, Firebind will tell its own server to listen on port 5190, and will send traffic back and forth from your machine to our server on that port. If the traffic is successfully sent and received, it's highly likely that the Internet provider is not blocking the use of your application. If the test traffic fails you'll know immediately that the Internet provider is more than likely blocking the application.

There is a broad spectrum of Firebind users, from road warriors connecting to the Internet from airports and hotels, to college students accessing the Internet from campus, and even corporate users trying to reach the Internet from their desks. Whatever your situation, Firebind was designed to help you connect, because a machine full of applications that rely on Internet access is useless if you can't reach your server.

Passed: The port is not blocked.

Handshake Connection Initiation Failure: For TCP port testing, this indicates there was a client problem initiating the 3-way handshake with the server in order to establish a TCP socket (the client was unable to send the SYN packet to start the handshake process.) This error is possible but uncommon, and would be considered an edge case. For UDP port testing, this is not applicable.

Handshake Connection Refused: For TCP port testing, this indicates that while the client was trying to establish a 3-way handshake with the server, upon sending the initial SYN packet, the client received back a TCP RESET (TCP RST) from an intervening firewall, forcing the client to close the connection. This is one of the 2 common methods of firewall blocking of TCP ports. For UDP port testing, this is not applicable.

Handshake Connection Timed Out: For TCP port testing, this indicates that while the client was trying to establish a 3-way handshake with the server, upon sending the initial SYN packet, the client received no response from the server, indicating that an intervening firewall silently discarded (dropped) the SYN packet. This is one of the 2 common methods of firewall blocking of TCP ports. For UDP port testing, this is not applicable.

Handshare Connection Completion Failure: For TCP port testing, this indicates there was a problem completing the 3-way handshake to establish a socket. An example of this could be the client losing its network connection during the handshake process. This error is possible but uncommon, and would be considered an edge case. For UDP port testing, this is not applicable.

Payload Send Failure: For TCP or UDP port testing, this indicates the client had a problem sending the payload to the server. This error is possible but uncommon, and would be considered an edge case.

Payload Receive Time Out: For TCP port testing, this indicates that the client was able to complete the 3-way handshake (establish a socket), however, after sending the test payload, the client timed out waiting for a reply. The most likely case is that some intervening device (such as a firewall or proxy server) intercepted the connection and established the socket with the client (as opposed to the client establishing a socket directly with the Firebind server.) Then the firewall or proxy dropped the payload since the payload didn't meet the firewall or proxy criteria for passage. For UDP port testing, since there is no 3-way handshake (socket conenction), this generally indicates a firewall blocking UDP traffic for the given port.

Payload Receive Refused: For TCP port testing, this indicates the client was able to complete the 3-way handshake (establish a socket), however, after sending the test payload, the client received a TCP RESET (TCP RST) message, forcing the client to close the connection. The most likely case is that some intervening device (such as a firewall or proxy server) intercepted the connection and established the socket with the client (as opposed to the client establishing a socket directly with the Firebind server.) Then the firewall or proxy decided to forcibly close the connection since the payload didn't meet the firewall or proxy criteria for passage. For UDP port testing, this could indicate the client receiving back an ICMP Host Unreachable message.

Payload Receive Mismatch: For TCP port testing, this indicates the client was able to complete the 3-way handshake (establish a socket), however, after sending the test payload, the client received back a payload that did not match what it sent. The most likely case is that some intervening device (such as a firewall or proxy server) intercepted the connection and established the socket with the client (as opposed to the client establishing a socket directly with the Firebind server.) Then the firewall or proxy determined that the payload didn't match the criteria for passage. This is a common failure result for TCP port 25 which many ISPs will only allow SMTP traffic to pass through. In that example, the client tries to connect to the Firebind server on TCP port 25, but the ISP's firewall intercepts, trying to validate that the traffic is formatted as SMTP packets. It then sends a message back to the client warning it that only SMTP traffic is supported (which Firebind interprets as this error message of "Payload Receive Mismatch." For UDP port testing this indicates a similar scenario to TCP port testing except UDP doesn't have the handshake phase.

Payload Receive Error - For TCP or UDP port testing, this indicates some unknown error in the payload receive process. This error is possible but uncommon, and would be considered an edge case.

Registered Firebind users enjoy the following benefits:

1. Test an unlimited number of TCP or UDP ports (vs. 100 ports per test for a non-registered user)
2. Post messages in the Forums
3. Post comments to the Firebind Blog
4. Review test result history
5. Additional test customization options

We recommend the Applet client since it has no limitations and provides a greater level of detail, however, if you prefer the web-based client, please note the following Minimum browser requirements:

• Internet Explorer 8.0 or later (IE 7.0 and below is not supported)
• Mozilla Firefox 3.0 or later
• Safari 3.0 or later
• Google Chrome 2.0 or later

Regardless of your browser type, you must have javascript enabled to use the Firebind Web Client. Also note that anonymous users can only test 100 ports at a time, whereas registered users can run tests with an unlimited number of ports (for example, the entire 1-65535 TCP port range.)

It's also important to understand that all 4 browsers listed above prevent a small number of TCP Ports from being able to be used to transfer data due to security concerns. This limitation is what causes some tested TCP ports to be categorized as "Failed due to browser blocking."

The following TCP ports are blocked by each browser:

• Internet Explorer: 8.0: 19, 21, 25, 110, 119, 143, 220, 993
• Mozilla Firefox: 1, 7, 9, 11, 13, 15, 17, 19-23, 25, 37, 42-43, 53, 77, 79, 87, 95, 101-104, 109-111, 113, 115, 117, 119, 123, 135, 139, 143, 179, 389, 465, 512-515, 526, 530-532, 540, 556, 563, 587, 601, 636, 993, 995, 2049, 4045, 6000
• Safari: 1, 7, 9, 11, 13, 15, 17, 19-23, 25, 37, 42-43, 53, 77, 79, 87, 95, 101-104, 109-111, 113, 115, 117, 119, 123, 135, 139, 143, 179, 389, 465, 512-515, 526, 530-532, 540, 556, 563, 587, 601, 636, 993, 995, 2049, 4045, 6000
• Google Chrome: 1, 7, 9, 11, 13, 15, 17, 19-23, 25, 37, 42-43, 53, 77, 79, 87, 95, 101-104, 109-111, 113, 115, 117, 119, 123, 135, 139, 143, 179, 389, 465, 512-515, 526, 530-532, 540, 556, 563, 587, 601, 636, 993, 995, 2049, 4045, 6000

The problem is that if your browser blocks a TCP Port that you'd like to test, you can't validate that given port is open to the Internet. To our knowledge, IE, Safari, and Chrome do not provide a way to override the blocking. However, Firefox does provide a way to override its blocked ports and therefore allow you to use Firebind to test any of the 65535 TCP Ports.

Follow these steps to reconfigure Firefox to not block certain TCP Ports:

1. Launch Firefox and type "about:config" in the URL field
2. Right Click then choose "New", then "String", then enter "network.security.ports.banned.override" in the String field
3. In the Value field, enter the ports (comma separated) that you'd like Firefox to no longer block.

Therefore, if you'd like to configure Firefox to not block any ports (for example, if you'd like to test all 65,535 TCP ports) then you could either cut and paste the above list of blocked Firefox ports into the Value field, or simply enter 1-65535. Or if you'd like to simply override one port, such as 139, you could just enter that port in the Value field.

PLEASE NOTE THAT FIREBIND IS NOT RESPONSIBLE FOR ANY ISSUES THAT MAY ARISE DUE TO THE USER OVERRIDING THEIR FIREFOX SECURITY SETTINGS. THE USER ASSUMES ALL RISK.

This is the most frequent question we get and the source of quite a bit of confusion. Firebind is a path scanner, not a port scanner.

There are many hundreds if not thousands of port scanning tools available to download or use on the Internet, taking the form of client executables (windows .exe files or java jar files) or even web based services. A port scanner is meant to scan a specific machine (single IP device) and check it for open ports, also known as listener ports. The primary reason to perform a port scan is for security - users don't want unnecessary ports open on their machines since it could leave them vulnerable to a hacker.

For example, if a user unknowingly had the Remote Desktop Service running on their Windows XP PC, it could invite hackers to try to log in and take control of the machine. If a port isn't open, a hacker cannot connect to it, hence the need to strictly control what ports are open or not.

Hackers also use port scanners to try to find vulnerable machines that they can attack, whether that machine is a PC, Mac, Linux machine, or even Router or Gig-E Switch. But regardless of whether it's a user trying to scan their own machine for defensive reasons, or a hacker trying to break into a machine, port scanning is all about a specific IP address as the target.

Path scanning, on the other hand, is about validating that your IP device's "path" to the Internet is free from being blocked for the specific application(s) you'd like to run. Firebind doesn't ever send IP traffic to a third party IP address. We only send traffic from our Firebind Client on your IP device to our Internet-Hosted Firebind Server.

For example, let's say you're using an airport Wi-Fi connection and want to use your native IBM Lotus Notes E-mail client to connect back to your corporate mail server. Unless you're using some sort of tunneling protool like IPSec, that connection will use the native Notes TCP Port 1352. If your e-mail wouldn't connect, you might suspect the Wi-Fi firewall is blocking you. So you could connect to Firebind.com and run a test for TCP Port 1352. Our Firebind Client then would attempt to pass traffic between your client machine and our Firebind server over TCP Port 1352. If the traffic passed successfully, you'd know the problem you're having connecting isn't likely the Internet connection. If the port failed, you'd know it was no use in trying to continue to connect, and opt perhaps to use the Notes Web client (which runs over TCP Port 80.)

To our knowledge Firebind is the only turnkey "path scanner" available on the Internet. It has many uses, including the above example of validating whether your application should be able to connect or not through the Internet. But it also can be used as an ACL (access control list) validation tool for firewalls. Many corporate firewalls follow the practice of blocking all ports by default, and then only opening those TCP or UDP ports for which they know they have applications using. Until now there was no way to both easily and reliably validate those outbound rules. But with Firebind, a corporate firewall administrator can set the test for TCP or UDP ports 1-65535 (the full range) and confirm that each port is either allowed or blocked as desired.

The focus of Firebind is to test outbound connections from your IP device (PC, Mac, Mobile, etc.) to the Internet, with the idea being that if a test for a given TCP port passes, then your connection is "free and clear" of some intervening device like a firewall trying to block it.

When Firebind tests an individual TCP port, the Firebind Web Client sends traffic back and forth to the Firebind Server on that given TCP port. If the communication is successful, the port passes. If the port doesn't pass (meaning the communication failed), there are generally two types of failures:

1. The first failure scenario is a TCP TIMEOUT, whereby the Firebind Web Client sent traffic to the Server, but some device such as a firewall blocked that traffic (silently discarded it.) The Web Client waits 10 seconds and if no response is received from the Firebind Server, that port is categorized as a TCP TIMEOUT. The Java Applet client allows you to set the timeout threshold to either 3, 6, or 12 seconds.
2. The second failure scenario is a TCP RESET. In this case, the intervening device (firewall, etc.) intercepts the packet from the Firebind Web Client and sends back what is known as a TCP RESET, which instructs the Firebind Web Client to close the connection.

A TCP TIMEOUT can be thought of as a passive port blocking method since it simply ignores the packets and doesn't pass them along, whereas a TCP RESET is an active blocking method since it replies to the client device. Most advanced firewalls and even some home firewall/routers can be configured to block ports using either of these methods.

There are other instances where a port will fail Firebind testing but it isn't directly do to a TCP TIMEOUT or TCP RESET. In some cases your Internet provider (whether it be your home ISP or a WiFi hotspot) will be running a proxy server for certain ports. One of the most common examples is an SMTP Proxy on TCP Port 25. Many broadband providers will only allow SMTP traffic on that port, so if the message format isn't SMTP, the Firebind test will fail. The Firebind team is considering protocol specific tests in the future, but for now, a Firebind failure on certain ports like TCP Port 25 doesn't always mean that port won't pass traffic - it could just mean it will only pass specific types of traffic, such as SMTP.

Here is a more detailed explanation of TCP RESET and TCP TIMEOUT.

With the TCP protocol, before an application can send or receive data, it must create what is called a TCP/IP Socket. A socket is created with a 3-way handshake. This involves the client machine sending a packet of data to the target machine (called SYN for synchronize). The target machine then acknowledges the packet (via an ACK) while sending its own packet (a SYN) back to the client machine. The client machine then acknowledges (ACKs) the packet from the target machine. If this 3-way communication is successful, the handshake is considered successful and the socket is created. Once created, the user can now send data back and forth. A TCP TIMEOUT (also known as a network timeout) results when the client machine sends the original “SYN” packet and doesn’t receive any acknowledgement from the server. A TCP RESET (also known as connection refused) results when the client sends its initial “SYN” packet and the target machine (server) replies with a reset message (also known as a TCP RESET.) These are the two primary ways that a firewall will block a given port since if the socket cannot be created, no data transfer can occur.

Due to the proliferation of bandwidth hungry and sometimes malicious applications, Internet access providers (broadband, wireless hotspot, etc.) are choosing to block access to certain applications using firewall technology.

Unfortunately, most applications don’t expect to be blocked and don’t return any useful messages to help the user understand why their application is failing to connect. Firebind can determine with virtual certainty whether a firewall or other device is blocking access to eliminate the guesswork and prevent the user from wasting time.

Anyone can use Firebind, although mobile users who connect to the Internet via public broadband connections such as hotel rooms or wireless hotspots may find it most useful. Additionally, with the new Java Applet client launched in December users can now test any of the 65535 TCP or UDP ports to see whether any are blocked. This capability provides the easiest way for an IT Administrator to test outbound firewall rules.

Yes. Registered users are able to view all of their past test results.

Firebind currently transfers a generic payload to and from the Firebind Server. If the payload is successfully returned to the client intact, it generally means the tested port is not being blocked. Support for application specific payloads is being considered for a future release.

Firebind has 2 clients today. The web-based client uses Javascript. It's TCP only and is subject to some port limitations depending on which type of browser you are using. Additionally, the web client is limited in terms of how much visibility it can provide into the reason a port was blocked. The second client which was launched in December of 2010 is a Java Applet. It has no port limitations and can test both TCP and UDP ports. Due to the greater degree of control over the testing process that the Java Applet provides, we're able to provide more detailed feedback on the types of failures seen.