indy https error 10061

[RTollison 0]

Delphi 10.2, Indy 10.x

Just trying to understand why this works. 

i have a dll that uses https to connect to our server. Works 99% of all our clients but for some outliers i kept getting 10061 connection refused error. after a bunch of trial and error while working with clients IT dept we finally tried running fiddler to help track down the issue. this tracking had me add proxyparams.proxyserver and proxyport to track in fiddler. well it would work without error. after rollbacks and testing we discovered that by leaving the proxyserver 127.0.0.1 in place that it would work and connect to our server and do whatever was needed. now any time we get the 10061 our support sends over the proxyserver version of the dll.

what is the reason or area that we should look at to find the source of the issue to not have to use the workaround proxyserver.

we bypassed AV, firewall off and allow access from internet explorer (edge, chrome, firefox,...)

[Remy Lebeau 1396]

Rather than using the ProxyParams (which affects TIdHTTP's internal logic in how it handles HTTP/S requests), I would suggest using a packet sniffer like Wireshark to see the actual IP/Port that TIdHTTP is trying to connect to for a normal non-proxy request, and see whether that connection is actually going out over the network. The main causes of error 10061 are:

 

• the target IP is reachable by the client, but there is no TCP server running on the target Port
• there is a TCP server running on the target IP/Port, but it has too many pending connections in its backlog
• the connection is being blocking by an AV/firewall that is located anywhere on the network(s) between your client and target server.

 

Unfortunately, there is no way to know on the client side what the root cause of the error actually is, so the only thing the client can do is catch the error and retry the request, preferably after a short delay, in case the error is temporary.

Edited January 3 by Remy Lebeau

[RTollison 0]

i think(pretty sure) it is the third issue. all the other users are working fine and no pending connections. Our IT looked at the logs and showed nothing coming thru for this client. It just that the clients IT uninstalled the AV, turned off the Firewall and allowed access via IEs.  They insisted it was something on our end even though i could use clients credentials and it would work. I asked if they had something on their server that might limit access and of course they adamantly swore the was nothing else. I am pretty sure that we had the workstation cleared but when i wanted access to the server it was no unless you have something specific. So I posted here. I was trying to understand why a proxyserver would allow whatever blocking the dll would now work. 

Since our IT said that nothing was coming from that workstation/site i guessed that the clients server has to be blocking the connection request but some clients IT are pretty touchie about letting a crazy dev on their system opening up connections.

 

Thank you and i will take time to understand wireshark instead of fiddler.

[Lars Fosdal 1792]

Charles Proxy is also good for sniffing out http/https issues.

[Remy Lebeau 1396]

4 hours ago, RTollison said:

i think(pretty sure) it is the third issue. all the other users are working fine and no pending connections. Our IT looked at the logs and showed nothing coming thru for this client. It just that the clients IT uninstalled the AV, turned off the Firewall and allowed access via IEs.

Are the client and server on the same LAN? If not, then there could be other AVs/Firewalls present in between the client and server as the connection jumps from one network to another.

4 hours ago, RTollison said:

I was trying to understand why a proxyserver would allow whatever blocking the dll would now work. 

The only thing that makes sense given what you have described is if there is a local AV/Firewall running on the client machine that is blocking the connections from TIdHTTP directly, but has an exception which allows Fiddler to make connections.

 

You say your TIdHTTP code is in a DLL, what app is loading that DLL?

 

[Kas Ob. 121]

15 hours ago, Remy Lebeau said:

Quote

 

I was trying to understand why a proxyserver would allow whatever blocking the dll would now work. 

The only thing that makes sense given what you have described is if there is a local AV/Firewall running on the client machine that is blocking the connections from TIdHTTP directly, but has an exception which allows Fiddler to make connections.

I second that, it is app control by either Windows Firewall or Defender or 3rd party firewall.

 

Remember that the default behavior on Windows can be adjusted with a policy, so the firewall could blocking public access for outgoing, while allowing home network and/or private network, this explain that behavior, so the old application have a policy while the installed local proxy adjusted its firewall role.

 

in other words the application that using this DLL is marked by firewall or some security software, and it might be not visible in the simple outgoing roles setting.

[mvanrijnen 123]

19 hours ago, Lars Fosdal said:

Charles Proxy is also good for sniffing out http/https issues.

haha, you have stocks in that ? 😉 

(i still have to compare it to mitm)

 

[RTollison 0]

yes all of our clients are on their own LAN. The original site with issue happened about 3 yrs ago and got "resolved" by adding the proxyserver. all of our clients get the non proxyserver version. but along the way some other outlier sites ,3-5 maybe, would have the same 10061 error and we send over the proxyserver version of dll and they work.

as for the original workstations we stripped that thing like a banana and still it would not connect. When I said it must be something on their server and that is pretty much where the investigation ended. Then last month i had a support rep ask where was the "special" version of the dll because a client was getting the 10061 error. So before sending over the odd dll i asked client if I could do some testing. the first thing i did was ask clients IT to allow an AV exception for the folder that has our software/dlls in it. No affect. IT then un-installed the AV and still no affect. next the site and I started on the firewall and again they just turned it off with no affect. they then went into all the ie's installed on workstation setting an allow access to our URL, no affect. So we decided to move on for now and I sent the odd dll over and it worked. so clients IT, turned firewall on and installed AV and then tested again and it worked still. when i said "maybe" something on the server is blocking access and asked if I could just look around and was shut off. "We don't allow anyone else direct access to our server!" verbatim. 

The thing of it is, over two months ago this very client was working without the proxyserver version and i asked what on their system changed we got the standard issue of 'nothing changed except we installed windows updates and your software updates'. we didn't change anything related to this feature and windows update has done anything to any of our other clients (> 1,200). I even asked the IT what software they recently installed on that server they said nothing. I just know something was done on the server since the workstation had nothing on it to block any traffic. 

[Lars Fosdal 1792]

17 hours ago, mvanrijnen said:

haha, you have stocks in that ? 😉 

(i still have to compare it to mitm)

 

Nope. I bought a license, though. Invaluable for sorting out the authentication protocol issues I had.