Error: "System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host" on test server

Question

I am facing an issue where my Web API is working fine on local systems but creating issues when deployed on server. I have checked, cross-checked multiple times to see if I have missed anything from the config, but everything is in order. Below is the code I am using. The line throwing this error is: using (WebResponse webResponse = webRequest.EndGetResponse(asyncResult))

        public static string PostDataToWebService(string stream, string CustIP)
    {
        var _url = AdditionalSetting.AutoEuroURL;
        string soapResult = string.Empty;
        try
        {
            XmlDocument soapEnvelopeXml = CreateSoapEnvelope(stream);
            HttpWebRequest webRequest = CreateWebRequest(_url, CustIP);
            InsertSoapEnvelopeIntoWebRequest(soapEnvelopeXml, webRequest);
            IAsyncResult asyncResult = webRequest.BeginGetResponse(null, null);
            asyncResult.AsyncWaitHandle.WaitOne();
            using (WebResponse webResponse = webRequest.EndGetResponse(asyncResult))
            {
                using (StreamReader rd = new StreamReader(webResponse.GetResponseStream()))
                {
                    soapResult = rd.ReadToEnd();
                }
            }
        }
        catch (WebException wbex)
        {
            using (var ResStream = wbex.Response.GetResponseStream())
            using (var reader = new StreamReader(ResStream))
            {
                ErrorLog.ErrorLogs("WebException at AutoEurope Call web service : " + reader.ReadToEnd());
            }
        }
        return soapResult;
    }


    private static XmlDocument CreateSoapEnvelope(string stream)
    {

        XmlDocument soapEnvelop = new XmlDocument();
        try
        {
            soapEnvelop.LoadXml(stream);
        }
        catch (Exception ex)
        {

        }
        return soapEnvelop;
    }

    private static HttpWebRequest CreateWebRequest(string url, string CustIP)
    {
        HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create(url);
        webRequest.Headers.Add("SOAPAction", "OTA");
        webRequest.Headers.Add("X-Forwarded-For", "\"" + CustIP + "\"");
        webRequest.ContentType = "text/xml;charset=\"utf-8\"";
        webRequest.Accept = "text/xml";
        webRequest.Method = "POST";
        webRequest.KeepAlive = false;
        webRequest.ProtocolVersion = HttpVersion.Version10;
        return webRequest;
    }

    private static void InsertSoapEnvelopeIntoWebRequest(XmlDocument soapEnvelopeXml, HttpWebRequest webRequest)
    {
        using (Stream stream = webRequest.GetRequestStream())
        {
            soapEnvelopeXml.Save(stream);
        }
    }

The CustIP I am getting is the request IP address which I am getting as a parameter in my method. It is in a proper format. Any suggestion would be helpful.

Solution

If you're getting this error between the BeginGetResponse() and EndGetResponse(), then there are a few possibilities:

• A lot of time is passing between the Begin and End, and the server is timing out. This can be checked with extra logging.
• The server is unhappy with what you have sent it and has closed the connection. Which isn't the problem here as you tested this sucessfully from a different machine.
• If the URL is an HTTPS URL, then this error can be caused by problems during TLS negotiation. While the TCP connection was established, the client and server couldn't agree on TLS parameters for the connection, and one side closed the connection before your request was sent.

The best way to check for TLS issues is to log onto to the test server and try to access the URL within a web browser such as Google Chrome or Internet Explorer. You can't use FireFox to test here as FireFox uses it's own implementation of TLS so might be able to succeed where Chrome, IE and .NET cannot.

If you cannot navigate to the site using a browser, then it most likely:

• The client doesn't TRUST the certificate that was sent by the server. Normally this is very easy to detect using a web browser, and can be resolved by either getting the server to use a publicly signed certificate, or by you verifying and deciding to trust the root certificate used by the server. This can also be that the server is misconfigured and is not sending an intermediate certificate.
• The test system and the server do not support the same TLS/SSL versions. TLS v1.2 is the only TLS version that ia considered secure, and many systems are locked down (via the registry) to disable TLS v1.1, v1.0 and SSL v3 and v2.
• The two systems do not support the same cipher suites. Again this can be because system configuration disallows those ciphers, or the system simply doesn't support them.

If you have the option of installing WireShark and learning about TLS handshaking, then this may be the quickest way to determine why the systems can't communicate as you can just see the problem directly and it removes a lot of guesswork.

Often, issues such as this are because either the client or the server are using an obsolete operating system. A Windows 95 client is very unlikely to be able to connect to an HTTPS website running on the latest version of OpenSUSE because they are just too different. Specifically it's unlikely that Windows 95 supports anything other than SSLv3 with basic cipher suites such as RC4, neither of which are likely to be supported on a recent OpenSUSE because they are considered insecure these days. Even Windows Server 2003 is too old to support TLS v1.1 or v1.2. Check the version of the operating system, and again this will be highlighted by WireShark.

Update

If you're unable to connect to the service and it's publicly available, you can use the online SSL Tester at https://www.ssllabs.com/ssltest/ to verify that the server is responding correctly.

In this case (with the address you gave in the comments), the problem is that the server is not responding correctly to any connections, even unsecured HTTP connections to port 80. You would have to contact the server's support department and have them investigate the issue.

Hope this helps

Comments

[krs]

Some network errors are firewall related. Did you tried to disable firewall or at least add enabling rule?

[Trevor]

Is the URL to which you are connecting an HTTP or HTTPS URL? If it's HTTPS, then issues during TLS negotiation can cause this. Also, consider logging a message just before BeginGetResponse() so that you can see how much time passes between Begin and End. If it is connecting, but then your code isn't responding, the server may be timing out and closing the connection.

[Trevor]

Also, try changing your asynchronous Begin()/WaitOne()/End() for a synchronous GetResponse(). You're using an asynchronous method for getting the response, but then blocking the first thread anyway.

[Amit Verma]

@krs I cannot disable the firewall and related to adding enabling rule, how can I do that?

[Amit Verma]

@Trevor All my requests are HTTPS and that is what is required to access the service.

[Amit Verma]

@Trevor I tried using GetResponse but the issue remains the same.

[Trevor]

@AmitVerma Have you tried visiting the URL from a web browser on the test server (even better if you can do it with the same user under which the code runs)? If there are firewall or Certificate trust issues that are specific to that machine, this may help to highlight them.

[Amit Verma]

@Trevor Thanks for the suggestion (I was not able to visit the URL successfully from server), it at least confirmed that its not my code that's causing the issue. Now the error I am getting is following: "This page can't be displayed Turn on TLS 1.0, TLS 1.1 and TLS 1.2 in advance settings and try connecting to again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4, which is not considered secure." I checked and all the mentioned TLS's are turned on. Can you please suggest any fix for this one?

[Trevor]

Are you allowed to publish the URL to which you are connecting? If so, I can check it from here to see if it has an unusual or obsolete cipher suite. If TLS negotiation is failing, then it's either A) TLS protocol (which you checked), B) Cipher Suites, C) Certificate Trust Issues, or D) something obscure. Either way, I think we're happy the code is correct. You may want to update the question with the new information. I'll write up an answer to help others.

[Amit Verma]

@Trevor The link I am using is "abequal.autoeurope.com". Can you please check.

[Trevor]

@AmitVerma Ok, there's the problem, the server is not either not working properly or not configured correctly. I'm unable to connect from here (the server connects, but does not respond to a TLS 1.2 handshake), and trying it with SSL labs ( ssllabs.com/ssltest/… ) gives the error "Assessment failed: No secure protocols supported". Even the HTTP site on port 80 is not responding correctly. You'd have to contact their support team. Sorry I can't be of more help.