What do the firewall test failure messages mean?

The Firescan agent is able to send custom payload sequences between itself and Reflector over any TCP or UDP port. This allows connection, transmission and reception of a payload to occur at the socket level. Operating this low in the network stack gives Reflector the ability to collect detailed information about why a payload test between Firescan and Reflector wasn't able to be successfully transmitted.  Different failure cases exhibit different patterns and for these cases the following categories have been created to assist in troubleshooting your connection issue.

Handshake Connection Refused

For TCP-based payload testing, this indicates that while Firescan was trying to establish a 3-way handshake with Reflector, upon sending the initial SYN packet, the Firescan received back a TCP RESET (TCP RST) from an intervening network device such as a firewall, forcing Firescan to close the connection. This is one of the 2 common methods of firewall blocking of TCP ports. For UDP payload testing, this is not applicable.

Payload Receive Refused

For TCP-based payload testing, this indicates Firescan was able to complete the 3-way handshake (establish a socket), however, after sending the payload, the Firescan received a TCP RESET (TCP RST) message, forcing Firescan 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 Firescan (as opposed to Firescan establishing a socket directly with Reflector.) 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-based payload testing, this could indicate that Firescan received back an ICMP Host Unreachable message.

Payload Receive Time Out

For TCP-based payload testing, this indicates that Firescan was able to complete the 3-way handshake (establish a socket), however, after sending the payload, Firescan 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 Firescan (as opposed to Firescan establishing a socket directly with Reflector.) Then the firewall or proxy dropped the payload since the payload didn't meet the firewall or proxy criteria for passage. For UDP-based path testing, since there is no 3-way handshake (socket conenction), this generally indicates a firewall blocking UDP traffic for the given port.

Handshake Connection Timed Out

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

Payload Receive Error

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

Handshake Connection Initiation Failure

For TCP-based payload testing, this indicates there was a Firescan problem initiating the 3-way handshake with Reflector in order to establish a TCP socket (Firescan 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-based payload testing, this is not applicable.

Payload Receive Mismatch

For TCP-based payload testing, this indicates that Firescan was able to complete the 3-way handshake (establish a socket), however, after sending the payload, Firescan 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 Firescan (as opposed to Firescan establishing a socket directly with Reflector.) 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 whereby many ISPs will only allow SMTP traffic to pass through. In that example, Firescan tries to connect to Reflector 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 Firescan warning it that only SMTP traffic is supported (which Firebind interprets as this error message of "Payload Receive Mismatch." For UDP-based path testing this indicates a similar scenario to TCP port tesing except UDP doesn't have the handshake phase.

Payload Send Failure

For TCP or UDP payload testing, this indicates that Firescan had a problem sending the payload to Reflector. This error is possible but uncommon, and would be considered an edge case.