Interpreting Results

Results will show a port was open or closed.  Open means the payload sequence completed successfully between customer agent and Firebind target without being modified.  Closed means that the payload sequence failed in some way for the given port. 

TCP Failure Messages

1. 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 network device, 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.

2. 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.

3. 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 target.) 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 connection), this generally indicates a firewall blocking UDP traffic for the given port.

4. 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.

5. Payload Receive Error

For TCP or UDP port testing, this indicates some unknown error in the payload receive process. This could occur because the remote system closed the connection during an attempt to receive data. This error is possible but uncommon, and would be considered an edge case.

6. 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.

7. 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 target 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.

8. 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.