[stunnel-users] RFC: purge use of keyword 'transparent'

[Michal Trojnara]

Oscar Usifer wrote:

> I am using the most current versions to date for each software  
> stacks. All use the same stunnel.conf file.

Ok.

> setuid = root
> setgid = root

Interesting.  What did you want to achieve with these options?

> rpminit# stunnel -version
> stunnel 4.33 on amd64-portbld-freebsd8.1 with OpenSSL 0.9.8n 24 Mar  
> 2010

"transparent" option is not currently supported on FreeBSD platform.   
The manual clearly lists supported platforms.

> [foo at localhost ~]$ uname -a
> Linux localhost.localdomain 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14  
> EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

"transparent" option is not currently supported on this Linux 2.6  
earlier than 2.6.28.  You need to upgrade your kernel.

> stunnel 4.15 on x86_64-redhat-linux-gnu with OpenSSL 0.9.8e-fips- 
> rhel5 01 Jul 2008

This stunnel is too old.  You need at least version 4.28:
http://stunnel.mirt.net/?page=ChangeLog_sdf

> Linux ubuntu 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC  
> 2010 x86_64 GNU/Linux
> Source: stunnel4
> Version: 3:4.29-1

This one meets basic requirements.  That's a good start.

> root at ubuntu:~# tcpdump -i any port 80
> tcpdump: verbose output suppressed, use -v or -vv for full protocol  
> decode
> listening on any, link-type LINUX_SLL (Linux cooked), capture size  
> 65535 bytes
>
> 13:29:34.794295 IP 192.168.103.69.40886 > localhost.www: Flags [S],  
> seq 3983439445, win 32792, options [mss 16396,sackOK,TS val 46696  
> ecr 0,nop,wscale 6], length 0
> 13:29:37.801619 IP 192.168.103.69.40886 > localhost.www: Flags [S],  
> seq 3983439445, win 32792, options [mss 16396,sackOK,TS val 46997  
> ecr 0,nop,wscale 6], length 0
> 13:29:43.811568 IP 192.168.103.69.40886 > localhost.www: Flags [S],  
> seq 3983439445, win 32792, options [mss 16396,sackOK,TS val 47598  
> ecr 0,nop,wscale 6], length 0

SYN packets are properly generated (IP_TRANPARENT was issued by  
stunnel and accepted by kernel), but the no response is generated.   
We're almost there.

> 2011.01.07 13:29:34 LOG6[990:140669015144192]: local_bind succeeded  
> on the original port
> 2011.01.07 13:29:34 LOG6[990:140669015144192]: connect_blocking:  
> connecting 127.0.0.1:80
> 2011.01.07 13:29:34 LOG7[990:140669015144192]: connect_blocking:  
> s_poll_wait 127.0.0.1:80: waiting 10 seconds
> 2011.01.07 13:29:44 LOG3[990:140669015144192]: connect_blocking:  
> s_poll_wait 127.0.0.1:80: timeout

That's basically the same information as seen by stunnel.

My guess is that those SYN packets were rejected for some reasons.
In order to locate the mechanism that caused it you could try to:
  - Check the output of "dmesg" for any rejected packets.
  - Disable your firewall.
  - Disable reverse patch filtering on other interfaces.
  - Change the IP address of "connect" option to the IP of a different  
interface (other than loopback).  You could also try to connect a  
service on a separate host (just make sure your stunnel host is a  
default gateway for this separate host).

> Yes. FYI as a test case, if it was as easy as reading the above  
> document, there would be no RFC. In regards to, http://www.stunnel.org/faq/transparent.html

Yes - stunnel.org is a serious problem to me.  It's outdated,  
confusing, and it violates my trademark of "stunnel".  I could use a  
help of a lawyer experienced in UDRP.  Can anyone help me?

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20110107/3e9ea749/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20110107/3e9ea749/attachment.sig>