Hello,
I'm having problems using stunnel. I would be glad to provide further information upon request. The funny thing is that it was working before I shipped the client pc to the remote location. Nothing has changed since.
Here's what I get in the logs:
CLIENT: ssmtp accepted FD=8 from 127.0.0.1:32844 FD 8 in non-blocking mode ssmtp started ssmtp connected from 127.0.0.1:32844 FD 9 in non-blocking mode ssmtp connecting 62.21.201.224:465 remote connect #1: EINPROGRESS: retrying waitforsocket: FD=9, DIR=write waitforsocket: ok Remote FD=9 initialized SSL state (connect): before/connect initialization SSL state (connect): SSLv3 write client hello A waitforsocket: FD=9, DIR=read waitforsocket: ok SSL state (connect): SSLv3 read server hello A SSL state (connect): SSLv3 read server certificate A SSL state (connect): SSLv3 read server certificate request A SSL state (connect): SSLv3 read server done A SSL state (connect): SSLv3 write client certificate A SSL state (connect): SSLv3 write client key exchange A SSL state (connect): SSLv3 write certificate verify A SSL state (connect): SSLv3 write change cipher spec A SSL state (connect): SSLv3 write finished A SSL state (connect): SSLv3 flush data waitforsocket: FD=9, DIR=read waitforsocket: ok SSL_connect: Peer suddenly disconnected ssmtp finished (0 left)
SERVER: ssmtp accepted FD=8 from 77.34.26.143:32845 FD 8 in non-blocking mode ssmtp started ssmtp connected from 77.34.26.143:32845 SSL state (accept): before/accept initialization SSL state (accept): SSLv3 read client hello A SSL state (accept): SSLv3 write server hello A SSL state (accept): SSLv3 write certificate A SSL state (accept): SSLv3 write certificate request A SSL state (accept): SSLv3 flush data SSL_accept: Peer suddenly disconnected ssmtp finished (0 left)
============================================
CLIENT INFO: stunnel 4.05 on i386-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.7e 25 Oct 2004
Global options cert = /etc/stunnel/stunnel.pem ciphers = ALL:!ADH:+RC4:@STRENGTH debug = 5 key = /etc/stunnel/stunnel.pem pid = /var/run/stunnel4/stunnel.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes session = 300 seconds verify = none
Service-level options TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTidle = 43200 seconds
------------------
SERVER INFO: stunnel 4.09 on x86_64-pc-linux-gnu PTHREAD+POLL+IPv6+LIBWRAP with OpenSSL 0.9.7e 25 Oct 2004
Global options cert = /etc/stunnel/stunnel.pem ciphers = ALL:!ADH:+RC4:@STRENGTH debug = 5 key = /etc/stunnel/stunnel.pem pid = /var/lib/run/stunnel.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes session = 300 seconds verify = none
Service-level options TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds
stunnel-users-bounces@mirt.net wrote on 26-09-2005 19:17:55:
Hello,
I'm having problems using stunnel. I would be glad to provide further information upon request. The funny thing is that it was working before I shipped the client pc to the remote location. Nothing has changed
since.
They symptoms appear to me to be consistent with a firewall between the client and the server terminating the connection when it sees traffic that doesn't fit its view of what the protocol it expects on port 465 to be.
I see this all the time because I work with FTP/TLS, which goes on port 21 like normal FTP, but some common firewall configurations sever the connection when it switches to SSL and the firewall starts seeing non-ASCII bytes, or long strings of bytes without CRLFs.
However, port 465 is designated for SMTP over TLS, so this wouldn't seem likely to be a common firewall configuration. The fact that it worked when the client was on a different network supports the theory that it's firewall related.
Here's what I get in the logs:
CLIENT: ssmtp accepted FD=8 from 127.0.0.1:32844 FD 8 in non-blocking mode ssmtp started ssmtp connected from 127.0.0.1:32844 FD 9 in non-blocking mode ssmtp connecting 62.21.201.224:465 remote connect #1: EINPROGRESS: retrying waitforsocket: FD=9, DIR=write waitforsocket: ok Remote FD=9 initialized SSL state (connect): before/connect initialization SSL state (connect): SSLv3 write client hello A waitforsocket: FD=9, DIR=read waitforsocket: ok SSL state (connect): SSLv3 read server hello A SSL state (connect): SSLv3 read server certificate A SSL state (connect): SSLv3 read server certificate request A SSL state (connect): SSLv3 read server done A SSL state (connect): SSLv3 write client certificate A SSL state (connect): SSLv3 write client key exchange A SSL state (connect): SSLv3 write certificate verify A SSL state (connect): SSLv3 write change cipher spec A SSL state (connect): SSLv3 write finished A SSL state (connect): SSLv3 flush data waitforsocket: FD=9, DIR=read waitforsocket: ok SSL_connect: Peer suddenly disconnected ssmtp finished (0 left)
SERVER: ssmtp accepted FD=8 from 77.34.26.143:32845 FD 8 in non-blocking mode ssmtp started ssmtp connected from 77.34.26.143:32845 SSL state (accept): before/accept initialization SSL state (accept): SSLv3 read client hello A SSL state (accept): SSLv3 write server hello A SSL state (accept): SSLv3 write certificate A SSL state (accept): SSLv3 write certificate request A SSL state (accept): SSLv3 flush data SSL_accept: Peer suddenly disconnected ssmtp finished (0 left)
============================================
CLIENT INFO: stunnel 4.05 on i386-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.7e 25 Oct 2004
Global options cert = /etc/stunnel/stunnel.pem ciphers = ALL:!ADH:+RC4:@STRENGTH debug = 5 key = /etc/stunnel/stunnel.pem pid = /var/run/stunnel4/stunnel.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes session = 300 seconds verify = none
Service-level options TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTidle = 43200 seconds
SERVER INFO: stunnel 4.09 on x86_64-pc-linux-gnu PTHREAD+POLL+IPv6+LIBWRAP with OpenSSL 0.9.7e 25 Oct 2004
Global options cert = /etc/stunnel/stunnel.pem ciphers = ALL:!ADH:+RC4:@STRENGTH debug = 5 key = /etc/stunnel/stunnel.pem pid = /var/lib/run/stunnel.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes session = 300 seconds verify = none
Service-level options TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds
stunnel-users mailing list stunnel-users@mirt.net http://stunnel.mirt.net/mailman/listinfo/stunnel-users
I'm 99.9% sure its not my firewalls that are the culprits because while I was testing I had the client pc running behind the same firewall/router that I shipped along with the client pc. So that puts the client side firewall out of the equation. Now for the server side, I tested that by setting my home pc as the client and connecting to my work server. That worked perfectly. So that takes the server side firewall out of the equation too. What's left is the client side ISP (Direcway satellite service), which is the only option available in the client location.
What I know about Direcway:
* They are not VPN friendly (they state that on their website). I do not consider an SSL tunnel as a VPN but... * If you do run a VPN, your connection speed drops by 50% (unless you buy some extra hardware from them), but it should still work even if you do not invest in the extra hardware * The latency on that connection is mortal. Just try SSH on you will know (between 0.6 and 2.5 seconds per keystroke)
Also, I played around with the timeout counters on boths sides but that did not help. Specifically, TIMEOUTconnect and TIMEOUTclose. One setup that did work, curiously enough, was switching roles between server and client. When I turned the client pc into the server and vice versa, it worked flawlessly.
I'm fresh out of ideas.
John Hartnup1 wrote:
stunnel-users-bounces@mirt.net wrote on 26-09-2005 19:17:55:
Hello,
I'm having problems using stunnel. I would be glad to provide further information upon request. The funny thing is that it was working before I shipped the client pc to the remote location. Nothing has changed
since.
They symptoms appear to me to be consistent with a firewall between the client and the server terminating the connection when it sees traffic that doesn't fit its view of what the protocol it expects on port 465 to be.
I see this all the time because I work with FTP/TLS, which goes on port 21 like normal FTP, but some common firewall configurations sever the connection when it switches to SSL and the firewall starts seeing non-ASCII bytes, or long strings of bytes without CRLFs.
However, port 465 is designated for SMTP over TLS, so this wouldn't seem likely to be a common firewall configuration. The fact that it worked when the client was on a different network supports the theory that it's firewall related.
-
John Hartnup1 -
Mark Tabash