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@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@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