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