There are so many questions about this issue but none has been able to address my issue specifically and I have yet to find any valid explanation of the error itself:
The underlying connection was closed: The connection was closed unexpectedly
In our situation we are making a call to a 3rd Party API via SSL. On my local PC I can connect to that API make a request and get a response back, but on an IIS Production server I get this error. The API is using OAuth to authenticate.
What exactly does it mean. Is the request leaving our server and rejected by the remote server, or is it not even leaving our server and our system is preventing it from making the request.
Some more information incase anyone may know what the issue is:
No known changes to any networking, servers, routing, security (apparently)
No code changes recently
According to our own internal logging, the issue started off as an ocassional 403 Error-Forbidden then we saw a number of Cannot Connect to Remote Server. Eventually it failed with The underlying connection was closed: The connection was closed unexpectedly.
Can someone please explain what the actual error means? If anyone has experienced this in a similar situation and can shed some light, that would be greatly appreciated.
The underlying connection was closed: The connection was closed unexpectedly
This just says, that (probably the remote end) closed the TCP connection which underlies the SSL connection. Usually an SSL alert should be sent back on SSL related errors, but some stacks instead close the connection. It might also be that the peer does not expect SSL at all and thus closes the connection because of invalid data.
On my local PC I can connect to that API make a request and get a response back, but on an IIS Production server I get this error.
It is hard to say what the problem might be, but if this is not only the same API but also the same server then the problem must be related to differences in the client. This can be support in ciphers, TLS versions, client certificates etc which can be different between machines. If this is not even the same server you should make sure that the problem is not server related by contacting the non-working server with the working client.
A good idea is also to make a TCP dump (wireshark) and compare the handshakes.
More detailed problem analysis can only be done when you provide more details about the problem, see http://noxxi.de/howto/ssl-debugging.html#hdr2.2 on what might be useful information.
Related
In my application (c++) I have a service exposed as:
grpc foo(stream Request) returns (Reply) { }
The issue is that when the server goes down (CTRL-C) the stream on the client side keeps going indeed the
grpc::ClientWriter::Write
doesn't return false. I can confirm that using netstat I don't see any connection between the client and the server (apart a TIME_WAIT one that after a while goes away) and the client keeps calling that Write without errors.
Is there a way to see if the underlying connection is still up instead to rely on the Write return value ? I use grpc version 1.12
update
I discovered that the underlying channel goes in status IDLE but still the ClientWriter::Write doesn't report the error, I don't know if this is intended. During the streaming I'm trying now to reestablish a connection with the server every time the channel status is not GRPC_CHANNEL_READY
This could happen in a few scenarios but the most common element is a connection issue. We have KEEPALIVE support in gRPC to tackle exactly this issue. For C++, please refer to https://github.com/grpc/grpc/blob/master/doc/keepalive.md on how to set this up. Essentially, endpoints would send pings at certain intervals and expect a reply within a certain timeframe.
I'm writing server application which uses boost::asio, and libssl via its integration with boost::asio. When there is incoming connection, the first time the handshake succeeded, but after the connection is dropped and the client tries to connect again, the handshake fails with the error:
session id context uninitialized
Here has proposed solution with using SSL_OP_NO_TICKET option when the SSL context is initialized. I'm using it the following way:
m_sslContext.set_options(SSL_OP_NO_TICKET);
In the beginning this resolves the problem, but now despite the option is still set the error appears again. Does anybody has an idea what other can be done with this problem?
I found that when the problem arises I still have an old connection to the same remote endpoint which tries to connect again. When I dropped the old connection properly the problem gone.
I got exactly the same error with client certificate verification enabled.
The solution was to create separate ssl_context for every connection, unlike in boost.asio examples.
One thing to note, SSL stream shutdown never completed in my case, it just would hang indefinitely. Perhaps, because the client didn't implement it correctly.
sorry for the noobish question but I can't find any resources online clearly stating whether this should work or not, and all tutorials / sample code always use localhost ^^ Soooo...
I'm trying to setup a simple server / client using RakNet. I'm literally just following the first tutorial (http://www.jenkinssoftware.com/raknet/manual/tutorial.html), just trying to get the client to connect to the server and keep the connection alive for a bit.
It all works great as long as I use 127.0.0.1 or 192.168.0.XXX, I can start the server, then the client, the server detects the connection request and sends the reply to the client, the client receives the reply and prints out "connection accepted" and such, and I can exchange messages between the client and the server.
However if I try using my actual IP, the server does not seem to detect the connection request (if you look at the tutorial code, it doesn't print "incoming connection"), but the client still receives a reply from somewhere ("Our connection request has been accepted").
After this initial semi-successful connection, no more packets will be received by either server or client, and the client will inevitably get disconnected after a few seconds (I assume time out?).
Port is open on the router, and the app runs fine as long as I keep it on localhost.
So my question is: is it even possible to run a server and client on the same machine / IP which is sitting behind a router?
The RakNet documentation part about NAT punchthrough and UDP forwarding does mention no more than one client and server being able to run on the same machine, but I was under the impression that one server / one client would not be an issue?
Thanks in advance to anybody who can shed some light on this!!
Forgot to mention my firewall is disabled !
I'm sorry if my question was answered already, but I cannot find it yet.
I'm using C++ and connection pool to connect to a PostgreSQL database in a Win32 console application. It runs OK at the beginning. However, after a while the program received an error: "Server closed the connection unexpectedly. This probably means the server terminated abnormally before or while processing the request".
When I open the PostgreSQL log file, it shows message: "unexpected EOF on client connection, could not receive data from client: No connection could be made because the target machine actively refused it."
Thank you for any help.
This really sounds like a network problem. I would be looking first at firewalls, then switches. I don't think a cable or a bad network card could cause a problem like this.
What sounds like is going on is that a connection is getting reset. If you eliminate network issues, then the next area to blame is the connection pooling software. Look at switching this out and see if the problem persists.
I am writing a proxy server that proxies SSL connections, and it is all working perfectly fine for normal traffic. However when there is a large file transfer (Anything over 20KB) like an email attachment, then the connection is reset on the TCP level before the file is finished being written. I am using non-blocking IO, and am spawning a thread for each specific connection.
When a connection comes in I do the following:
Spawn a thread
Connect to the client (unencrypted) and read the connect request (all other requests are ignored)
Create a secure connection (SSL using openssl api) to the server
Tell the client that we contacted the server (unencrypted)
Create secure connection to client, and start proxying data between the two using a select loop to determine when reading and writing can occur
Once the underlying sockets are closed, or there is an error, the connection is closed, and thread is terminated.
Like I said, this works great for normal sized data (regular webpages, and other things) but fails as soon as a file is too large with either an error code (depending on the webapp being used) or a Error: Connection Interrupted.
I have no idea what is causing the connection to close, whether it's something TCP, HTTP, or SSL specific, and I can't find any information on it at all. In some browsers it will start to work if I put a sleep statement immediately after the SSL_write, but this seems to cause other issues in other browsers. The sleep doesn't have to be long, really just a delay. I currently have it set to 4ms per write, and 2ms per read, and this fixes it completely in older firefox, chrome with HTTP uploads, and opera.
Any leads would be appreciated, and let me know if you need any more information. Thanks in advanced!
-Sam
If the web-app thinks an uploaded file is too large what does it do? If it's entitled to just close the connection, that will cause an ECONN at the sender: 'connection reset'. Whatever it does, as you're writing a proxy, and assuming there are no bugs in your code that are causing this, your mission is to mirror whatever happens to your upstream connection back down the downstream connection. In this case the answer is to just do what you're doing: close the upstream and downstream sockets. If you got an incoming close_notify from the server, do an orderly SSL close to the client; if you got ECONN, just close the client socket directly, bypassing SSL.