14

When I execute the following command in Ubuntu:

 curl -v --insecure -XGET 'https://user:pass@IP_ADDR:PORT/SOME_FILE.php'

I get this output:

* Hostname was NOT found in DNS cache
*   Trying IP_ADDR...
* Connected to IP_ADDR (IP_ADDR) port PORT (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):

And after several minutes I get this:

* Unknown SSL protocol error in connection to IP_ADDR:PORT 
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to IP_ADDR:PORT

When I try the same thing in CentOS I still get stuck in Client Hello, but in the end I get this:

curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received

Does anyone knows what can cause it and how can I fix it?

Improve this question
2
  • Your script at the beginning, and the output of that script are not consistent. You script does not include 82.166.236.100. Also, it would be helpful if you could give a complete self-contained example that people could actually run.
    – Faheem Mitha
    Jan 3, 2016 at 9:36
  • Take a look to curl.haxx.se/mail/tracker-2014-11/0046.html
    – 林果皞
    Jan 3, 2016 at 13:21

4 Answers 4

Reset to default
14

We suffered the same exact issue and the cause was an MTU misconfiguration, but there are many other possible causes.

The key was to sniff traffic on our edge router, where we saw ICMP messages to the server (GitHub.com) asking for fragmentation. This was messing the connection, with retransmissions, duplicated ACKs and so.

enter image description here

The ICMP packet had a field, MTU of next hop with a weird value, 1450. The usual value is 1500.

enter image description here

We checked our router and one of the interfaces (an Ethernet tunnel) had this value as MTU, so the router was taking the minumun MTU of all interfaces as next hop. As soon as we removed this interface (it was unused), the SSH handshake started to work again.

Improve this answer
3
  • 1
    saved me a day, thank you!
    – Roman Dodin
    Nov 25, 2020 at 8:53
  • 1
    For me the problem occurred in a situation where docker is running in a cloud server launched by Gitlab Runner and the cloud (OpenStack) has limited the MTU to 1450. The fix was to have { "mtu": 1450 } in /etc/docker/daemon.json file.
    – jpe
    Nov 9, 2021 at 13:35
  • 1
    Thanks! Once I got off my vpn, I was able to complete my request.
    – JellicleCat
    Aug 23 at 0:01
4

I meet same problem with two infrastructure connected through OpenVPN.

Curl don't work with https/http

Charli's solution was right for me.

I followed this link : https://www.sonassi.fr/help/troubleshooting/setting-correct-mtu-for-openvpn.

So to find the right MTU you can use this command : 

bryan@debian-dev11@ping -c 1 -M do -s 1472 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 1472(1500) bytes of data.
1480 bytes from 10.0.0.5: icmp_seq=1 ttl=126 time=6.19 ms

Where 1472 is the MTU that you test

And a response with bad MTU

bryan@debian-dev11:~$ ping -c 1 -M do -s 1474 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 1474(1502) bytes of data.
ping: local error: Message too long, mtu=1500

your target server's firewall must accept icmp/echo requests.

In my specific case, i was behind two router, trough two nat rules one behind the other. When the packet arrived on the final host, the final host was requesting missing part other the gateway and not the original ip.. so, request couldn't arrive to the original host.

Improve this answer
1

My guess is that you attempt to use https against a server:port where https is not available at all. In this case the server still waits for the end of the HTTP request while your client waits for the server to continue with the SSL handshake. Check if you can access the exact same URL with https with a browser.

Improve this answer
0

I do not have enough points to comment, but charli's answer helped me with a problem setting up masquerading. However I could not remove the device as in my case it was the outgoing ppp0 connection.

In this case it helped for me to reduce the other clients' mtu to the ppp0 device value (1492) either directly or via dhcpd configuration. In this case the symptoms were problems with TLS handshakes when trying to fetch emails (only with some servers) and with video streaming from other clients.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .