# Curl with https from inside a user container failing

**URL:** https://forums.suse.com/t/curl-with-https-from-inside-a-user-container-failing/9855
**Category:** General
**Created:** [March 23, 2018, 3:02pm UTC](https://forums.suse.com/t/curl-with-https-from-inside-a-user-container-failing/9855 "2018-03-23T15:02:36Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![updiversity](https://avatars.discourse-cdn.com/v4/letter/u/d9b06d/32.png) [@updiversity](https://forums.suse.com/u/updiversity)
#### Post date: [March 23, 2018, 3:02pm UTC](https://forums.suse.com/t/curl-with-https-from-inside-a-user-container-failing/9855/1 "2018-03-23T15:02:36Z")

</div>

Hi,

I have been investigating for a week now on why i am observing this behaviour, but unfortunately I could not sort it out on my own ☹

Basically, i am trying use the following curl command from inside one of my container running in a Rancher Cattle environment.

curl -v -u \<user\>:\<password\> [https://api.github.com/user](https://api.github.com/user)

the SSL negotiation is stuck always at the same point:

```
* Hostname was NOT found in DNS cache
* Trying 192.30.253.117...
* Connected to api.github.com (192.30.253.117) port 443 (#0)
* 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 key exchange (12):
* 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 TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=*.github.com
* start date: 2017-01-18 00:00:00 GMT
* expire date: 2020-04-17 12:00:00 GMT
* subjectAltName: api.github.com matched
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
* Server auth using Basic with user '<user>'
> GET /user HTTP/1.1
> Authorization: <key>
> User-Agent: curl/7.38.0
> Host: api.github.com
> Accept: */*
>

```

However, if i launch the same command from the containers that are not managed by the IPSEC network, then it works perfectly. I tried it with the following containers with success:

- rancher-agent
- ipsec-cni-driver
- ipsec-ipsec

while if i try from the following containers, it fails:

- healthcheck
- scheduler  
or any user container deployed on the managed network

I’d like to understand a bit more why this is happening, is it related to the ipsec default routing configuration, is it related to the MTU configuration ? etc…

Finally, I think it is important to mention that curl works perfectly on all the containers if the target server does not require an authentication.