MFT Gateway Outbound Message Failures

MFT Gateway encounters these errors as the sender when a message either fails to transmit to the partner AS2 system or fails processing at the partner’s end. MFT Gateway usually isolates such failed messages for easy identification, automatically retry the transmissions where applicable, and automatically alert the users in case of permanent failures.

Transmission/network Errors

AS2 operates over the unreliable HTTP protocol, so any error faced by the underlying network could affect the transmission of the message and the respective MDN.

Possible Symptoms and Error Messages

Error types: Connection timed out, Connection closed unexpectedly, Connection reset, Broken pipe

These errors indicate that the communication between MFT Gateway and the partner was interrupted while data was being transmitted.

Note that in this scenario, there is no guarantee whether the remote system received the message or not before the transmission failed. Therefore, before resending the message, it is recommended to confirm with the partner whether the message was already received and processed successfully on their end.

Steps to resolve:

• Contact the partner to confirm if the message was received and processed successfully on their end.
• Retry the transmission only after you have confirmed that the message did not reach to the partner.

Error types: Connect timed out, Connection refused

The MFT Gateway was unable to establish a connection with the partner’s endpoint.

Note that this is different from the connection time-out mentioned above.

Common causes:

• An incorrect hostname on the partner URL.
• A firewall on the partner’s side blocking the incoming connection from MFT Gateway.
• A temporary downtime/maintenance of the partner endpoint.

Steps to resolve:

• Ensure that you have configured the correct partner URL when creating the partner.
• Enable static IP address for MFT Gateway outbound messages if whitelisting is required on the partner’s end and share the IP with the partner to be whitelisted on their end.

Note that this option is only available to Business and Enterprise subscription tiers. If you enable this option, you will need to subscribe to such a tier after your free trial ends.

• Once the connectivity issue is resolved, it is safe to resend the message, as it is guaranteed that the partner did not receive the message earlier.

Error types: Unknown host, Host resolution failed

MFT Gateway was unable to resolve the IP address of the partner URL.

Common causes:

• An incorrect hostname in the partner URL.
• The partner URL is on a private network and is not accessible from the MFT Gateway.

Steps to resolve:

• Ensure that you have configured the correct partner URL when creating the partner.
• Some IP ranges are reserved for private networks. If the URL uses a hostname, the corresponding IP address can be found by performing a DNS lookup from the command line, for example by running nslookup {partner.hostname}.

Error types: SSL Handshake Exception

When the partner URL is a secure one (with https:// protocol prefix), the transmission can start only if the MFT Gateway can create a secure connection to the partner endpoint by means of a TLS handshake.

This handshake can fail due to various reasons:

• Two parties are unable to agree upon a common TLS version or set of cipher suites/algorithms for the secure connection.
• The TLS/HTTPS certificate of the partner (server) is not trusted by the MFT Gateway (client) (trust anchor not found or untrusted certificate).
• Hostname (or alternative domain name) in server’s TLS certificate does not match the actual domain name in the client side URL (hostname verification failure).
• The partner’s server expects TLS client authentication (two-way handshake).
• In rare cases, intermediate proxies/firewalls may drop certain packets related to secure/TLS communication.

Steps to resolve:

• If MFT Gateway currently does not trust the SSL certificate of the partner endpoint, configure the corresponding HTTPS (TLS/SSL) certificate to the partner.
• If the partner expects TLS client authentication (two-way handshake), configure a TLS/SSL key pair to the station.

HTTP Response Code Analysis

Sometimes the network transfer succeeds, but the remote system returns an error, indicating an HTTP-level (application layer) transaction failure. These usually follow the standard HTTP error response code semantics. But some AS2 systems may just return a generic server error (500) code, in which cases it may be necessary to contact the partner team and request for more details to understand the actual problem.

Here, one would need to check the response code (and possibly the reason phrase), headers, and the response body if available, to get an idea of the failure cause. A typical HTTP response contains these parts arranged as follows:

HTTP/{protocol version} {response code} {reason phrase}

{response header 1}
{response header 2}
...

{response body}