[stunnel-users] sTunnel client connecting to load balanced URL - stunnel 5.02 on x86-pc-msvc-1500 platform

Mon Mar 19 10:54:29 CET 2018

IMO the problem has nothing to do with the alias. Of course, this IP hosts
the service. Both DNS names point to the same IP address as you can see
below:

$ dig l4884-iflmap.hcisbp.eu1.hana.ondemand.com

l4884-iflmap.hcisbp.eu1.hana.ondemand.com. 0 IN    CNAME
EU1571393051174.ssl.ondemand.com.
EU1571393051174.ssl.ondemand.com. 3361 IN A    155.56.210.164

You may try to set the *sni* = SERVER_NAME parameter to see if it helps.

https://www.stunnel.org/static/stunnel.html

Regards,
Flo Rance

On Mon, Mar 19, 2018 at 5:56 AM, Tony <nissan4x4 at optusnet.com.au> wrote:

> Hi all,
>
> I have a situation where I’m trying to use sTunnel as the client to
> connect to a service on a secure URL, but the hiccup is that the secure URL
> is load balanced.
>
>
>
> If a do an nslookup on the URL, the response comes back as it being an
> alias.
>
>
>
> Non-authoritative answer:
>
> Name:    eu1571393051174.ssl.ondemand.com
>
> Address:  155.56.210.164
>
> Aliases:  l4884-iflmap.hcisbp.eu1.hana.ondemand.com
>
>
>
> Looking at the sTunnel log, it resolves to the IP of the server. But the
> IP itself does not host the service so I’m getting http:503 errors.
>
>
>
> 2018.03.16 14:44:44 LOG7[18796]: Service [ssl-OSRdev] (FD=564) bound to
> 0.0.0.0:8085
>
> 2018.03.16 14:44:55 LOG7[18796]: Service [ssl-OSRdev] accepted (FD=572)
> from 192.168.0.22:61093
>
> 2018.03.16 14:44:55 LOG7[18796]: Creating a new thread
>
> 2018.03.16 14:44:55 LOG7[18796]: New thread created
>
> 2018.03.16 14:44:55 LOG7[30864]: Service [ssl-OSRdev] started
>
> 2018.03.16 14:44:55 LOG5[30864]: Service [ssl-OSRdev] accepted connection
> from 192.168.0.22:61093
>
> 2018.03.16 14:44:55 LOG6[30864]: s_connect: connecting *155.56.210.164:443
> <http://155.56.210.164:443>*
>
> 2018.03.16 14:44:55 LOG7[30864]: s_connect: s_poll_wait 155.56.210.164:443:
> waiting 10 seconds
>
> 2018.03.16 14:44:56 LOG5[30864]: s_connect: connected 155.56.210.164:443
>
> 2018.03.16 14:44:56 LOG5[30864]: Service [ssl-OSRdev] connected remote
> server from 192.168.0.32:30269
>
> 2018.03.16 14:44:56 LOG7[30864]: Remote socket (FD=588) initialized
>
> 2018.03.16 14:44:56 LOG7[30864]: SNI: sending servername: *l4884-iflmap.hcisbp.eu1.hana.ondemand.com
> <http://l4884-iflmap.hcisbp.eu1.hana.ondemand.com>*
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): before/connect
> initialization
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv2/v3 write
> client hello A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 read server
> hello A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 read server
> certificate A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 read server
> key exchange A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 read server
> certificate request A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 read server
> done A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 write client
> certificate A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 write client
> key exchange A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 write
> certificate verify A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 write change
> cipher spec A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 write finished
> A
>
> 2018.03.16 14:44:56 LOG7[30864]: SSL state (connect): SSLv3 flush data
>
> 2018.03.16 14:44:57 LOG7[30864]: SSL state (connect): SSLv3 read finished A
>
> 2018.03.16 14:44:57 LOG7[30864]:    1 items in the session cache
>
> 2018.03.16 14:44:57 LOG7[30864]:    1 client connects (SSL_connect())
>
> 2018.03.16 14:44:57 LOG7[30864]:    1 client connects that finished
>
> 2018.03.16 14:44:57 LOG7[30864]:    0 client renegotiations requested
>
> 2018.03.16 14:44:57 LOG7[30864]:    0 server connects (SSL_accept())
>
> 2018.03.16 14:44:57 LOG7[30864]:    0 server connects that finished
>
> 2018.03.16 14:44:57 LOG7[30864]:    0 server renegotiations requested
>
> 2018.03.16 14:44:57 LOG7[30864]:    0 session cache hits
>
> 2018.03.16 14:44:57 LOG7[30864]:    0 external session cache hits
>
> 2018.03.16 14:44:57 LOG7[30864]:    0 session cache misses
>
> 2018.03.16 14:44:57 LOG7[30864]:    0 session cache timeouts
>
> 2018.03.16 14:44:57 LOG7[30864]: Peer certificate was cached (3826 bytes)
>
> 2018.03.16 14:44:57 LOG6[30864]: SSL connected: new session negotiated
>
> 2018.03.16 14:44:57 LOG6[30864]: Negotiated TLSv1/SSLv3 ciphersuite:
> ECDHE-RSA-AES128-GCM-SHA256 (128-bit encryption)
>
> 2018.03.16 14:44:57 LOG6[30864]: Compression: null, expansion: null
>
> 2018.03.16 14:44:58 LOG6[30864]: SSL socket closed (SSL_read)
>
> 2018.03.16 14:44:58 LOG7[30864]: Sent socket write shutdown
>
> 2018.03.16 14:44:58 LOG5[30864]: Connection closed: 1730 byte(s) sent to
> SSL, 274 byte(s) sent to socket
>
> 2018.03.16 14:44:58 LOG7[30864]: Remote socket (FD=588) closed
>
> 2018.03.16 14:44:58 LOG7[30864]: Local socket (FD=572) closed
>
> 2018.03.16 14:44:58 LOG7[30864]: Service [ssl-OSRdev] finished (0 left)
>
> 2018.03.16 14:44:58 LOG7[30864]: str_stats: 3 block(s), 4294962489 data
> byte(s), 150 control byte(s)
>
> 2018.03.16 14:44:58 LOG7[30864]: str_stats: 20 byte(s) at
> ..\src\network.c:413
>
> 2018.03.16 14:44:58 LOG7[30864]: str_stats: 20 byte(s) at
> ..\src\network.c:412
>
> 2018.03.16 14:44:58 LOG7[30864]: str_stats: 20 byte(s) at
> ..\src\network.c:411
>
>
>
> I have tested the service using SoapUI and it works.
>
>
>
> Is it possible to have sTunnel follow the URL redirection?
>
>
>
>
>
> Regards, Tony
>
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20180319/025a3f0a/attachment.html>