Thomas,
After a few exchanges a few hours ago with the folk at STunnel I can confirm
that the "problem" was that the company uses host headers. Here is the
procedure I used to sort it out:
1. Modify the windows host file and add the following entry 127.0.0.1
rest.nexmo.com. If your STunnel ir running on a different machines, set the
127.0.0.1 to the IP address of the Stunnel server.
2. Add the following to the stunnel.conf file (you may alter the port)
[nexmo]
client = yes
accept = 9013
connect = 174.120.166.82:443
TIMEOUTclose = 0
3. Start sending secure SMSs as follows (note the port number much match the
one set in stunnel.conf)
http://rest.nexmo.com:9013/sms/xml?username=xxxxxxx&password=xxxxxxx&from=xx
xxxxxx&to=xxxxxxx&text=xxxxxxx
This will bypass the issue related to host headers and I can confirm that
the solution has worked.
The setup is useful if using server technology that does not natively
support SSL as is our case.
Hope this helps.
Alan
----------------------------------------------------------------------------
----------------------------------------
Alan;
While I don't generally use Stunnel for HTTPS, I found your question
interesting. Since I'm always trying
to experiment with configurations of and applications for Stunnel, I
decided to give it a whirl.
I'm happy to confirm that it works just fine for me. I'm not connecting
to the site in your example,
but the principle is the same. Perhaps the answer lies in how your
browser parses that URL,
and how, as a result, it inserts that data into the stream.
For the experiment, I used Firefox 9.0.1 running under Windows XP x86
with Stunnel version 4.53.
My test config was:
debug = 6
fips = no
delay = yes
output = stunnel.log
[https]
client = yes
accept = 127.0.1.21:7777
connect = www.host.domain:443
Where www.host.domain is just an example. As you can see, I did not
include any
TIMEOUTclose statement in my config file.
Then I pointed the browser at
http://127.0.1.21:7777/do/mypage/longparameterstringhere.
As far as I can tell, all of the parameters contained in that string
were passed on to the web site without
any difficulty.
You might want to check your log window to see what's happening when you
try to connect via Stunnel.
Here's an actual example of the connection activity from my log:
2012.03.22 21:20:51 LOG5[992:2548]: Service [https] accepted connection
from ***.**.***.*:2671
2012.03.22 21:20:51 LOG6[992:2548]: connect_blocking: connecting
***.***.***.***:443
2012.03.22 21:20:51 LOG5[992:2548]: connect_blocking: connected
***.***.***.***:443
2012.03.22 21:20:51 LOG5[992:2548]: Service [https] connected remote
server from ***.**.***.*:2672
2012.03.22 21:20:51 LOG6[992:2548]: SSL connected: new session negotiated
2012.03.22 21:20:51 LOG6[992:2548]: Negotiated TLSv1/SSLv3 ciphersuite:
RC4-SHA (128-bit encryption)
2012.03.22 21:20:51 LOG6[992:2548]: Compression: null, expansion: null
2012.03.22 21:21:00 LOG6[992:2548]: SSL_shutdown successfully sent
close_notify alert
2012.03.22 21:21:00 LOG5[992:2548]: Connection closed: 1879 byte(s) sent
to SSL, 128546 byte(s) sent to socket
If you have to post again, it would be helpful if you included more detail.
Good luck with your application!
Thomas
On 3/21/2012 9:50 AM, Alan C. Bonnici wrote:
>
> Hi,
>
> I am new to STunnel. I am trying to connect to a service provided by
> nexmo.com.
>
> If from a browser I type the following:
>
>
https://rest.nexmo.com/sms/xml?username=xxxxxxx&password=xxxxx&from=xxxxxxx&
to=xxxxxxx&text=xxxxxxxxxx
>
<https://rest.nexmo.com/sms/xml?username=xxxxxxx&password=xxxxx&from=xxxxxxx
&to=xxxxxxx&text=xxxxxxxxxx>
>
> The process works.
>
> I just installed stunnel and have the following config file
>
> ; Debugging stuff (may useful for troubleshooting)
>
> ;debug = 7
>
> ;output = stunnel.log
>
> ; Certificate/key is needed in server mode and optional in client mode
>
> cert = stunnel.pem
>
> ;key = stunnel.pem
>
> ; Disable support for insecure SSLv2 protocol
>
> options = NO_SSLv2
>
> [nexmo]
>
> client = yes
>
> accept = 9012
>
> connect = rest.nexmo.com:443
>
> TIMEOUTclose = 0
>
> When I type
>
>
http://127.0.0.1:9012/sms/xml?username=xxxxxxx&password=xxxxx&from=xxxxxxx&t
o=xxxxxxx&text=xxxxxxxxxx
>
>
> it does not.
>
> Can anyone please confirm whether what I am trying to do is doable and
> maybe highlight what I am doing wrong.
>
> Regards,
>
> Alan
>
>
>
> _______________________________________________
> stunnel-users mailing list
> stunnel-users(a)stunnel.org
> http://stunnel.mirt.net/mailman/listinfo/stunnel-users
--
Attention: This message and all attachments are private and may contain
information that is confidential and privileged. If you received this
message in error, please notify the sender by reply email and delete the
message immediately.
1
0
Hi,
I am new to STunnel. I am trying to connect to a service provided by
nexmo.com.
If from a browser I type the following:
https://rest.nexmo.com/sms/xml?username=xxxxxxx
<https://rest.nexmo.com/sms/xml?username=xxxxxxx&password=xxxxx&from=xxxxxxx
&to=xxxxxxx&text=xxxxxxxxxx>
&password=xxxxx&from=xxxxxxx&to=xxxxxxx&text=xxxxxxxxxx
The process works.
I just installed stunnel and have the following config file
; Debugging stuff (may useful for troubleshooting)
;debug = 7
;output = stunnel.log
; Certificate/key is needed in server mode and optional in client mode
cert = stunnel.pem
;key = stunnel.pem
; Disable support for insecure SSLv2 protocol
options = NO_SSLv2
[nexmo]
client = yes
accept = 9012
connect = rest.nexmo.com:443
TIMEOUTclose = 0
When I type
http://127.0.0.1:9012/sms/xml?
username=xxxxxxx&password=xxxxx&from=xxxxxxx&to=xxxxxxx&text=xxxxxxxxxx
it does not.
Can anyone please confirm whether what I am trying to do is doable and maybe
highlight what I am doing wrong.
Regards,
Alan
2
1
Hi,
Nexmo offer (free trial) SMS messages that can be programmed into systems.
I've attached the log file when calling the service:
2012.03.22 10:41:13 LOG7[5024:8232]: No limit detected for the number of
clients
2012.03.22 10:41:13 LOG5[5024:8232]: stunnel 4.53 on x86-pc-mingw32-gnu
platform
2012.03.22 10:41:13 LOG5[5024:8232]: Compiled/running with OpenSSL
0.9.8s-fips 4 Jan 2012
2012.03.22 10:41:13 LOG5[5024:8232]: Threading:WIN32 SSL:+ENGINE+OCSP+FIPS
Auth:none Sockets:SELECT+IPv6
2012.03.22 10:41:13 LOG5[5024:8232]: Reading configuration from file
stunnel.conf
2012.03.22 10:41:14 LOG5[5024:8232]: FIPS mode is enabled
2012.03.22 10:41:14 LOG7[5024:8232]: Compression not enabled
2012.03.22 10:41:14 LOG7[5024:8232]: Snagged 64 random bytes from C:/.rnd
2012.03.22 10:41:14 LOG7[5024:8232]: Wrote 1024 new random bytes to C:/.rnd
2012.03.22 10:41:14 LOG7[5024:8232]: PRNG seeded successfully
2012.03.22 10:41:14 LOG6[5024:8232]: Initializing service section [nexmo]
2012.03.22 10:41:14 LOG7[5024:8232]: Certificate: stunnel.pem
2012.03.22 10:41:14 LOG7[5024:8232]: Certificate loaded
2012.03.22 10:41:14 LOG7[5024:8232]: Key file: stunnel.pem
2012.03.22 10:41:14 LOG7[5024:8232]: Private key loaded
2012.03.22 10:41:14 LOG7[5024:8232]: SSL options set: 0x01000004
2012.03.22 10:41:14 LOG5[5024:8232]: Configuration successful
2012.03.22 10:41:14 LOG7[5024:8232]: Service [nexmo] (FD=280) bound to
0.0.0.0:9012
2012.03.22 10:44:09 LOG7[5024:8232]: Service [nexmo] accepted (FD=444) from
127.0.0.1:3692
2012.03.22 10:44:09 LOG7[5024:8232]: Creating a new thread
2012.03.22 10:44:09 LOG7[5024:8232]: New thread created
2012.03.22 10:44:09 LOG7[5024:3280]: Service [nexmo] started
2012.03.22 10:44:09 LOG5[5024:3280]: Service [nexmo] accepted connection
from 127.0.0.1:3692
2012.03.22 10:44:09 LOG6[5024:3280]: connect_blocking: connecting
174.120.166.82:443
2012.03.22 10:44:09 LOG7[5024:3280]: connect_blocking: s_poll_wait
174.120.166.82:443: waiting 10 seconds
2012.03.22 10:44:09 LOG5[5024:3280]: connect_blocking: connected
174.120.166.82:443
2012.03.22 10:44:09 LOG5[5024:3280]: Service [nexmo] connected remote server
from 10.252.0.51:3693
2012.03.22 10:44:09 LOG7[5024:3280]: Remote socket (FD=476) initialized
2012.03.22 10:44:10 LOG7[5024:3280]: Peer certificate was cached (6499
bytes)
2012.03.22 10:44:10 LOG6[5024:3280]: SSL connected: new session negotiated
2012.03.22 10:44:10 LOG6[5024:3280]: Negotiated TLSv1/SSLv3 ciphersuite:
AES256-SHA (256-bit encryption)
2012.03.22 10:44:10 LOG6[5024:3280]: Compression: null, expansion: null
2012.03.22 10:44:10 LOG7[5024:3280]: SSL closed on SSL_read
2012.03.22 10:44:10 LOG7[5024:3280]: Sent socket write shutdown
2012.03.22 10:44:10 LOG7[5024:3280]: Socket closed on read
2012.03.22 10:44:10 LOG7[5024:3280]: Sending close_notify alert
2012.03.22 10:44:10 LOG6[5024:3280]: SSL_shutdown successfully sent
close_notify alert
2012.03.22 10:44:10 LOG5[5024:3280]: Connection closed: 388 byte(s) sent to
SSL, 200 byte(s) sent to socket
2012.03.22 10:44:10 LOG7[5024:3280]: Remote socket (FD=476) closed
2012.03.22 10:44:10 LOG7[5024:3280]: Local socket (FD=444) closed
2012.03.22 10:44:10 LOG7[5024:3280]: Service [nexmo] finished (0 left)
2012.03.22 10:44:10 LOG7[5024:8232]: Service [nexmo] accepted (FD=440) from
127.0.0.1:3694
2012.03.22 10:44:10 LOG7[5024:8232]: Creating a new thread
2012.03.22 10:44:10 LOG7[5024:8232]: New thread created
2012.03.22 10:44:10 LOG7[5024:8864]: Service [nexmo] started
2012.03.22 10:44:10 LOG5[5024:8864]: Service [nexmo] accepted connection
from 127.0.0.1:3694
2012.03.22 10:44:10 LOG6[5024:8864]: connect_blocking: connecting
174.120.166.82:443
2012.03.22 10:44:10 LOG7[5024:8864]: connect_blocking: s_poll_wait
174.120.166.82:443: waiting 10 seconds
2012.03.22 10:44:10 LOG5[5024:8864]: connect_blocking: connected
174.120.166.82:443
2012.03.22 10:44:10 LOG5[5024:8864]: Service [nexmo] connected remote server
from 10.252.0.51:3695
2012.03.22 10:44:10 LOG7[5024:8864]: Remote socket (FD=424) initialized
2012.03.22 10:44:10 LOG6[5024:8864]: SSL connected: previous session reused
2012.03.22 10:44:10 LOG7[5024:8864]: SSL closed on SSL_read
2012.03.22 10:44:10 LOG7[5024:8864]: Sent socket write shutdown
2012.03.22 10:44:10 LOG7[5024:8864]: Socket closed on read
2012.03.22 10:44:10 LOG7[5024:8864]: Sending close_notify alert
2012.03.22 10:44:10 LOG6[5024:8864]: SSL_shutdown successfully sent
close_notify alert
2012.03.22 10:44:10 LOG5[5024:8864]: Connection closed: 269 byte(s) sent to
SSL, 200 byte(s) sent to socket
2012.03.22 10:44:10 LOG7[5024:8864]: Remote socket (FD=424) closed
2012.03.22 10:44:10 LOG7[5024:8864]: Local socket (FD=440) closed
2012.03.22 10:44:10 LOG7[5024:8864]: Service [nexmo] finished (0 left)
2012.03.22 10:44:10 LOG7[5024:8232]: Service [nexmo] accepted (FD=460) from
127.0.0.1:3696
2012.03.22 10:44:10 LOG7[5024:8232]: Creating a new thread
2012.03.22 10:44:10 LOG7[5024:8232]: New thread created
2012.03.22 10:44:10 LOG7[5024:5820]: Service [nexmo] started
2012.03.22 10:44:10 LOG5[5024:5820]: Service [nexmo] accepted connection
from 127.0.0.1:3696
2012.03.22 10:44:10 LOG6[5024:5820]: connect_blocking: connecting
174.120.166.82:443
2012.03.22 10:44:10 LOG7[5024:5820]: connect_blocking: s_poll_wait
174.120.166.82:443: waiting 10 seconds
2012.03.22 10:44:11 LOG5[5024:5820]: connect_blocking: connected
174.120.166.82:443
2012.03.22 10:44:11 LOG5[5024:5820]: Service [nexmo] connected remote server
from 10.252.0.51:3697
2012.03.22 10:44:11 LOG7[5024:5820]: Remote socket (FD=476) initialized
2012.03.22 10:44:11 LOG6[5024:5820]: SSL connected: previous session reused
2012.03.22 10:44:11 LOG7[5024:5820]: SSL closed on SSL_read
2012.03.22 10:44:11 LOG7[5024:5820]: Sent socket write shutdown
2012.03.22 10:44:11 LOG7[5024:5820]: Socket closed on read
2012.03.22 10:44:11 LOG7[5024:5820]: Sending close_notify alert
2012.03.22 10:44:11 LOG6[5024:5820]: SSL_shutdown successfully sent
close_notify alert
2012.03.22 10:44:11 LOG5[5024:5820]: Connection closed: 299 byte(s) sent to
SSL, 200 byte(s) sent to socket
2012.03.22 10:44:11 LOG7[5024:5820]: Remote socket (FD=476) closed
2012.03.22 10:44:11 LOG7[5024:5820]: Local socket (FD=460) closed
2012.03.22 10:44:11 LOG7[5024:5820]: Service [nexmo] finished (0 left)
2012.03.22 10:44:11 LOG7[5024:8232]: Service [nexmo] accepted (FD=448) from
127.0.0.1:3698
2012.03.22 10:44:11 LOG7[5024:8232]: Creating a new thread
2012.03.22 10:44:11 LOG7[5024:8232]: New thread created
2012.03.22 10:44:11 LOG7[5024:8476]: Service [nexmo] started
2012.03.22 10:44:11 LOG5[5024:8476]: Service [nexmo] accepted connection
from 127.0.0.1:3698
2012.03.22 10:44:11 LOG6[5024:8476]: connect_blocking: connecting
174.120.166.82:443
2012.03.22 10:44:11 LOG7[5024:8476]: connect_blocking: s_poll_wait
174.120.166.82:443: waiting 10 seconds
2012.03.22 10:44:11 LOG5[5024:8476]: connect_blocking: connected
174.120.166.82:443
2012.03.22 10:44:11 LOG5[5024:8476]: Service [nexmo] connected remote server
from 10.252.0.51:3699
2012.03.22 10:44:11 LOG7[5024:8476]: Remote socket (FD=424) initialized
2012.03.22 10:44:11 LOG6[5024:8476]: SSL connected: previous session reused
2012.03.22 10:44:12 LOG7[5024:8476]: SSL closed on SSL_read
2012.03.22 10:44:12 LOG7[5024:8476]: Sent socket write shutdown
2012.03.22 10:44:12 LOG7[5024:8476]: Socket closed on read
2012.03.22 10:44:12 LOG7[5024:8476]: Sending close_notify alert
2012.03.22 10:44:12 LOG6[5024:8476]: SSL_shutdown successfully sent
close_notify alert
2012.03.22 10:44:12 LOG5[5024:8476]: Connection closed: 299 byte(s) sent to
SSL, 200 byte(s) sent to socket
2012.03.22 10:44:12 LOG7[5024:8476]: Remote socket (FD=424) closed
2012.03.22 10:44:12 LOG7[5024:8476]: Local socket (FD=448) closed
2012.03.22 10:44:12 LOG7[5024:8476]: Service [nexmo] finished (0 left)
-----------------------------------
Message: 4
Date: Wed, 21 Mar 2012 15:50:59 +0100
From: "Alan C. Bonnici" <chribonn(a)gmail.com>
To: <stunnel-users(a)stunnel.org>
Subject: [stunnel-users] Can this be done by Stunnel
Message-ID: <006b01cd0772$0869f3c0$193ddb40$(a)gmail.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
I am new to STunnel. I am trying to connect to a service provided by
nexmo.com.
If from a browser I type the following:
https://rest.nexmo.com/sms/xml?username=xxxxxxx
<https://rest.nexmo.com/sms/xml?username=xxxxxxx&password=xxxxx&from=xxxxxxx
&to=xxxxxxx&text=xxxxxxxxxx>
&password=xxxxx&from=xxxxxxx&to=xxxxxxx&text=xxxxxxxxxx
The process works.
I just installed stunnel and have the following config file
; Debugging stuff (may useful for troubleshooting)
;debug = 7
;output = stunnel.log
; Certificate/key is needed in server mode and optional in client mode
cert = stunnel.pem
;key = stunnel.pem
; Disable support for insecure SSLv2 protocol
options = NO_SSLv2
[nexmo]
client = yes
accept = 9012
connect = rest.nexmo.com:443
TIMEOUTclose = 0
When I type
http://127.0.0.1:9012/sms/xml?
username=xxxxxxx&password=xxxxx&from=xxxxxxx&to=xxxxxxx&text=xxxxxxxxxx
it does not.
Can anyone please confirm whether what I am trying to do is doable and maybe
highlight what I am doing wrong.
Regards,
Alan
1
0
Feature request: restricting incoming IP-adress to a list of allowed adresses
by Ivanko B 22 Mar '12
by Ivanko B 22 Mar '12
22 Mar '12
also possibly with smth like callback
2
1
Hi,
I've spent the better part of the day trying to find answers on this,
and haven't had much luck.
I have two systems that talk to eachother via stunnel. In the last week
or so, I have noticed a number of errors in the application using the
tunnel (messaging application), requiring multiple re-sends, etc.
This is my setup.
Both server and client run CentOS 6.2, with the RPM version of stunnel.
Though it isn't the latest version, I believe RedHat do release any
critical bugs in their updated RPMs. I did also go through the ChangeLog
but couldn't find anything implemented since 4.29 that seemed to deal
with what I'm seeing.
stunnel 4.29 on x86_64-unknown-linux-gnu with OpenSSL 1.0.0-fips 29 Mar 2010
Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6 Auth:LIBWRAP
Global options
debug = 5
pid = /var/run/stunnel.pid
RNDbytes = 64
RNDfile = /dev/urandom
RNDoverwrite = yes
Service-level options
cert = /etc/stunnel/stunnel.pem
ciphers = ALL:!aNULL:!eNULL:!SSLv2
key = /etc/stunnel/stunnel.pem
session = 300 seconds
stack = 65536 bytes
sslVersion = SSLv3 for client, all for server
TIMEOUTbusy = 300 seconds
TIMEOUTclose = 60 seconds
TIMEOUTconnect = 10 seconds
TIMEOUTidle = 43200 seconds
verify = none
Socket option defaults:
Option Accept Local Remote OS default
SO_DEBUG -- -- -- 0
SO_DONTROUTE -- -- -- 0
SO_KEEPALIVE -- -- -- 0
SO_LINGER -- -- -- 0:0
SO_OOBINLINE -- -- -- 0
SO_RCVBUF -- -- -- 87380
SO_SNDBUF -- -- -- 16384
SO_RCVLOWAT -- -- -- 1
SO_SNDLOWAT -- -- -- 1
SO_RCVTIMEO -- -- -- 0:0
SO_SNDTIMEO -- -- -- 0:0
SO_REUSEADDR 1 -- -- 0
SO_BINDTODEVICE -- -- -- --
TCP_KEEPCNT -- -- -- 9
TCP_KEEPIDLE -- -- -- 7200
TCP_KEEPINTVL -- -- -- 75
IP_TOS -- -- -- 0
IP_TTL -- -- -- 64
TCP_NODELAY -- -- -- 0
Common config (basically default file released by RedHat, with certs and
ports configured) :
----------------
; Protocol version (all, SSLv2, SSLv3, TLSv1)
sslVersion = SSLv3
; Some security enhancements for UNIX systems - comment them out on Win32
chroot = /var/run/stunnel/
setuid = stunnel
setgid = stunnel
; PID is created inside the chroot jail
pid = /stunnel.pid
; Some debugging stuff useful for troubleshooting
debug = 7
output = /var/log/stunnel.log
-------------------
When the connection breaks, the logs (debug=7) on both sides are:
Client:
2012.03.21 19:58:14 LOG7[30685:140185543952128]: SSL state (connect):
before/connect initialization
2012.03.21 19:58:14 LOG7[30685:140185543952128]: SSL state (connect):
SSLv3 write client hello A
2012.03.21 19:58:14 LOG3[30685:140185543952128]: SSL_connect: Peer
suddenly disconnected
2012.03.21 19:58:14 LOG5[30685:140185543952128]: Connection reset: 0
bytes sent to SSL, 0 bytes sent to socket
Server:
2012.03.21 19:58:14 LOG3[22230:140462283343616]: SSL_accept: Peer
suddenly disconnected
2012.03.21 19:58:14 LOG5[22230:140462283343616]: Connection reset: 0
bytes sent to SSL, 0 bytes sent to socket
As I mentioned, it happens intermittently, with probably 50% of the
connections working just fine, and the rest being disconnected. It
ALWAYS seems to happen just after the client 'write client hello A', as
opposed to later in the SSL handshake.
I ran a tcpdump on both sides, it is below. Note that both the client
and the server are NATd behind firewalls, on the server the port stunnel
listens on (31112) is opened through the firewall.
CLIENT (192.168.22.120, NATd externally as 66.66.66.66):
18:21:57.009887 IP 192.168.22.120.55747 > 77.77.77.77.31112: Flags [S],
seq 2556598106, win 14600, options [mss 1460,sackOK,TS val 88488311 ecr
0,nop,wscale 7], length 0
18:21:57.076130 IP 77.77.77.77.31112 > 192.168.22.120.55747: Flags [S.],
seq 351052925, ack 2556598107, win 14480, options [mss 1460,sackOK,TS
val 646044220 ecr 88488311,nop,wscale 7], length 0
18:21:57.076195 IP 192.168.22.120.55747 > 77.77.77.77.31112: Flags [.],
ack 1, win 115, options [nop,nop,TS val 88488377 ecr 646044220], length 0
18:21:57.077234 IP 192.168.22.120.55747 > 77.77.77.77.31112: Flags [P.],
seq 1:140, ack 1, win 115, options [nop,nop,TS val 88488378 ecr
646044220], length 139
18:21:57.143582 IP 77.77.77.77.31112 > 192.168.22.120.55747: Flags [.],
ack 140, win 122, options [nop,nop,TS val 646044288 ecr 88488378], length 0
18:21:57.143982 IP 77.77.77.77.31112 > 192.168.22.120.55747: Flags
[RP.], seq 1, ack 140, win 122, length 0
SERVER (10.65.0.130, NATd externally as 77.77.77.77):
18:21:57.042122 IP 66.66.66.66.7760 > 10.65.0.130.http: Flags [S], seq
4074124673, win 14600, options [mss 1460,sackOK,TS val 88488311 ecr
0,nop,wscale 7], length 0
18:21:57.042161 IP 10.65.0.130.http > 66.66.66.66.7760: Flags [S.], seq
458906148, ack 4074124674, win 14480, options [mss 1460,sackOK,TS val
646044220 ecr 88488311,nop,wscale 7], length 0
18:21:57.108325 IP 66.66.66.66.7760 > 10.65.0.130.http: Flags [.], ack
1, win 115, options [nop,nop,TS val 88488377 ecr 646044220], length 0
18:21:57.109507 IP 66.66.66.66.7760 > 10.65.0.130.http: Flags [P.], seq
1:140, ack 1, win 115, options [nop,nop,TS val 88488378 ecr 646044220],
length 139
18:21:57.109532 IP 10.65.0.130.http > 66.66.66.66.7760: Flags [.], ack
140, win 122, options [nop,nop,TS val 646044288 ecr 88488378], length 0
18:21:57.110092 IP 10.65.0.130.http > 66.66.66.66.7760: Flags [P.], seq
1:178, ack 140, win 122, options [nop,nop,TS val 646044288 ecr
88488378], length 177
18:21:57.175518 IP 66.66.66.66.7760 > 10.65.0.130.http: Flags [R.], seq
140, ack 1, win 115, length 0
Based on what I am seeing, a mysterious RST packet gets received by both
sides, which causes them to terminate the session. Neither side
originates any RST packets. When the connection is successful, the
tcpdump looks a lot more normal, with an appropriate FIN exchange
closing the session once the data has been sent.
My questions are - am I missing something obvious? Am I correct in
reading the above as some firewall or router between the two servers
breaking the TCP connection by sending TCP RSTs to both endpoints?
any help is appreciated.
jordan
1
0
Hello
To follow up on my test, I would like to try and run stunnel from inetd
However I wonder if anyone has an experience, suggestions, and some
inetd.conf examples. I read it was possible in the FAQ but I didn't
see a lot of examples
Should I use a configuration file (for the global parameters) then
specify connect= params?
ex :
443 stream tcp6 nowait nobody /sbin/stunnel /etc/stunnel.conf
connect=127.0.0.1:80 TIMEOUTclose=0
Thanks
Guylhem
1
0
Hello
I've read that EDH calculations were ca cause of significant slow up
on http://matt.io/technobabble/hivemind_devops_alert:_nginx_does_not_suck_at_s…
I'm running stunnel on a embedded Linux/MIPS, where I'm trying to
light up the load.
Is it possible to disable EDH? If so, how? I couldn't find any info on that.
Thanks
Guylhem
2
3
Hello,
Here is my setup :
[PCA]-------------[Firewall-A]---------------{INTERNET}-----------[45.212.56.178:21213|Firewall-B|192.168.0.1:8139]--------[PCB]
PCA : Windows 7
stunnel.conf :
[smb]
client = yes
accept = 10.232.232.232:139
connect = 45.212.56.178:21213
PCB : Ubuntu Oneiric 11.10
stunnel.conf :
[smb]
accept = 8139
connect = 139
When I try to connect a network drive from PCA to a remote drive of PCB
here are the stunnel.log of PCA :
2012.03.19 13:47:02 LOG5[3744:2564]: Reading configuration from file
stunnel.conf
2012.03.19 13:47:02 LOG5[3744:2564]: FIPS mode is enabled
2012.03.19 13:47:02 LOG7[3744:2564]: Compression not enabled
2012.03.19 13:47:02 LOG7[3744:2564]: Snagged 64 random bytes from
C:/.rnd
2012.03.19 13:47:02 LOG7[3744:2564]: Wrote 0 new random bytes to
C:/.rnd
2012.03.19 13:47:02 LOG7[3744:2564]: PRNG seeded successfully
2012.03.19 13:47:02 LOG6[3744:2564]: Initializing SSL context for
service smb
2012.03.19 13:47:02 LOG7[3744:2564]: Certificate: stunnel.pem
2012.03.19 13:47:02 LOG7[3744:2564]: Certificate loaded
2012.03.19 13:47:02 LOG7[3744:2564]: Key file: stunnel.pem
2012.03.19 13:47:02 LOG7[3744:2564]: Private key loaded
2012.03.19 13:47:02 LOG7[3744:2564]: SSL options set: 0x01000004
2012.03.19 13:47:02 LOG6[3744:2564]: SSL context initialized
2012.03.19 13:47:02 LOG5[3744:2564]: Configuration successful
2012.03.19 13:47:02 LOG7[3744:2564]: Service smb closed FD=200
2012.03.19 13:47:13 LOG5[3744:3940]: Service smb accepted connection
from 10.232.232.232:50004
2012.03.19 13:47:13 LOG5[3744:3940]: connect_blocking: connected
45.212.56.178:21213
2012.03.19 13:47:13 LOG5[3744:3940]: Service smb connected remote
server from 192.168.3.4:50005
2012.03.19 13:47:43 LOG3[3744:3940]: readsocket: Connection reset by
peer (WSAECONNRESET) (10054)
2012.03.19 13:47:43 LOG5[3744:3940]: Connection reset: 143 bytes sent
to SSL, 0 bytes sent to socket
No logs on PCB
it seems that the SSL connection doesn't cross the firewall B, if not I
would saw logs in stunnel.log of PCB isn't it ?
What can I do better to make this setup working ? Does the firewall B
porforwarding is blocking the process ?
Best regards
Philippe
4
10
Hello,
I use Stunnel with Windows.
The configuration file "stunnel.conf" and the log file "stunnel.log" are in
the %USERAPPDATA%\Stunnel folder.
Stunnel starts and works without problems. But the GUI options "Edit
stunnel.conf" and "Reload stunnel.conf" do not work.
Is remedy possible?
Sebastian
2
3
19 Mar '12
I have found the stunnel version on PCB : stunnel 4.35 on
x86_64-pc-linux-gnu with OpenSSL 1.0.0e 6 Sep 2011
the version on PCA is 4.52 this is perhaps a too big difference isn't
it ?
Best
Philippe
1
0