moby: curl fails inside container on https connection

I come up with a problem that curl fails on this request from inside a docker container, but succeeds from the host machine. Any ideas why? Both host and container are ubuntu:12.04. The problem is in openssl, because I am having the same issue when requesting from my Twisted app.

curl -kv https://ws.eisto.kz/sms/sms.ashx?regnumber=1-a167lko
* About to connect() to ws.eisto.kz port 443 (#0)
*   Trying 93.185.75.48... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
*    subject: CN=INSP.EISTO.KZ; serialNumber=IIN800517301165; C=KZ; L=\U0410\U0421\U0422\U0410\U041D\U0410; ST=\U0410\U0421\U0422\U0410\U041D\U0410; O=\U0410\U041A\U0426\U0418\U041E\U041D\U0415\U0420\U041D\U041E\U0415 \U041E\U0411\U0429\U0415\U0421\U0422\U0412\U041E "\
*    start date: 2013-08-21 04:15:55 GMT
*    expire date: 2014-08-21 04:15:55 GMT
*    subjectAltName: ws.eisto.kz matched
*    issuer: CN=\U041D\U0423\U0426 \U0420\U041A (RSA); OU=\U0418\U043D\U0444\U0440\U0430\U0441\U0442\U0440\U0443\U043A\U0442\U0443\U0440\U0430 \U043E\U0442\U043A\U0440\U044B\U0442\U044B\U0445 \U043A\U043B\U044E\U0447\U0435\U0439; O=\U041D\U0430\U0446\U0438\U043E\U043D
*    SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET /sms/sms.ashx?regnumber=1-a167lko HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: ws.eisto.kz
> Accept: */*
> 
* SSLv3, TLS handshake, Hello request (0):
* SSLv3, TLS handshake, Client hello (1):
* SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
* Closing connection #0
curl: (56) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104

Curl version

curl 7.29.0 (x86_64-pc-linux-gnu) libcurl/7.29.0 OpenSSL/1.0.1c zlib/1.2.7 libidn/1.25 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

About this issue

Original URL
State: closed
Created 11 years ago
Comments: 25 (4 by maintainers)

Commits related to this issue

Merge pull request #2011 from pradipd/lbfix Move load balancer sandbox creation/deletion into libnetwork. — committed to cpuguy83/docker by deleted user 7 years ago

Most upvoted comments

This issue can be worked around by setting a lower mtu in the docker daemon, e.g.:

]# cat /etc/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
After=network.target docker.socket
Requires=docker.socket

[Service]
ExecStart=/usr/bin/docker daemon -H tcp://0.0.0.0:2376  \
  -H unix:///var/run/docker.sock \
  --storage-driver devicemapper \
  --label provider=generic \
  --mtu=1200
MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity
Environment=

+10

alvaroaleman on Jul 23, 2016

I was never on a VPN, instead it might be related to me using Docker-inside-Docker (CI Build step). I added the DOCKER_OPTS=“–mtu 1400” and it worked!

Thanks @alvaroaleman And thx @amacneil for ensuring the solution is last comment 😃

So again, if you have anything fancy network wise, try this env var: DOCKER_OPTS="--mtu 1400"

justsml on Nov 16, 2016

Beware that docker-compose doesn’t inherit mtu value. If you are using docker-compose, then you have to set mtu value explicitly in docker-compose.yml:

networks:                                
  default:                               
    driver: bridge                       
    driver_opts:                         
      com.docker.network.driver.mtu: 1458

armezit on Sep 1, 2020

If you are using VPN with protocol wireguard change it to protocol openvpn

dramer-817 on Sep 29, 2022

thanks @glaszig, I’m not running in a vm (atm), and it looks like LRO should be off and it’s apparently already off on my machine:

$ ethtool -k eth0
Features for eth0:
...
large-receive-offload: off [fixed]


$ ethtool -k docker0
Features for docker0:
...
large-receive-offload: off [fixed]

so, I’m not sure what to do here.

dayer4b on Mar 11, 2015

Thanks @alvaroaleman! In my case I was also on a VPN (ipsec) which was preventing https connections to github.com inside docker.

On Ubuntu 14.04, fixed by adding this line in /etc/default/docker:

DOCKER_OPTS="--mtu 1400"

amacneil on Oct 7, 2016