Folks,
After searching, installing various Linuces (in the 2.6 family), e.g. CentOS, Ubuntu, and so on, I have not been able to get transparent proxy working at all. As such since it the function does not work, and there is great debate as to whether it ever worked, I would like to propose that this keyword and reference to its function be discarded entirely. This will save many folks a great deal of time and effort attempting to try and get it to work, myself having spent over 80 hours (including my precious holiday time) trying to dig, scratch, research up old posts that say it works or someone has it working under such and such a configuration! The documentation itself has folks claiming that it works and does not, which is really a bad practice. Why did you perpetuate this option in the first place?!
I hope you see the importance and reason with my request and act immediately.
... Unless someone really really does have it working.
Thank you
Am 07.01.2011 03:26, schrieb [email protected]:
Folks,
After searching, installing various Linuces (in the 2.6 family), e.g. CentOS, Ubuntu, and so on, I have not been able to get transparent proxy working at all. As such since it the function does not work, and there is great debate as to whether it ever worked, I would like to propose that this keyword and reference to its function be discarded entirely. This will save many folks a great deal of time and effort attempting to try and get it to work, myself having spent over 80 hours (including my precious holiday time) trying to dig, scratch, research up old posts that say it works or someone has it working under such and such a configuration! The documentation itself has folks claiming that it works and does not, which is really a bad practice. Why did you perpetuate this option in the first place?!
I hope you see the importance and reason with my request and act immediately.
... Unless someone really really does have it working.
Thank you
stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users
While I have not even tried to use the "transparent" function (stunnel runs on Windows in our environment, where "transparent" is not supported), I would like to add my two cents: For a ssl tunnel solution like stunnel, a "transparent" option is a very basic necessity. Having all connections to the application come from 127.0.0.1 makes trouble shooting and auditing very problematic. Therefore, transparent operations should be the default, not an afterthought only available on one platform.
I therefore counter-propose to make this option work, and make it work on all supported platforms. While I know that this will probably not be possible, since it would require a lot of programming work to be done, I nevertheless wanted to make it clear, that this option is not unnecessary and should not be simply discarded.
Greetings Markus Borst
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Markus Borst wrote:
I therefore counter-propose to make this option work, and make it work on all supported platforms. While I know that this will probably not be possible, since it would require a lot of programming work to be done, I nevertheless wanted to make it clear, that this option is not unnecessary and should not be simply discarded.
That would be great. Unfortunately required feature (commonly called "non-local bind") is not available within standard BSD sockets interface.
In fact the generic solution requires serious modification of TCP/IP stacks (located in OS kernels). This is not portable and hardly practical, especially with closed-source kernels (such us Microsoft Windows kernel).
Things get a bit easier when "connect" target is on the same machine, allowing for a userspace solution. Unfortunately it's still not a portable approach. One way to achieve this goal on Windows might be DLL injection: https://secure.wikimedia.org/wikipedia/en/wiki/DLL_injection
Mike
Dear Oscar,
"Oscar Usifer" [email protected] wrote:
After searching, installing various (in the 2.6 family), e.g. CentOS, Ubuntu, and so on, I have not been able to get transparent proxy working at all.
LOL: http://catb.org/~esr/faqs/smart-questions.html#id479555
Could you please try to be a bit more specific (e.g. in terms of your stunnel and kernel versions, configuration, logs, packet captures, etc.)?
As such since it the function does not work, and there is great debate as to whether it ever worked, I would like to propose that this keyword and reference to its function be discarded entirely. This will save many folks a great deal of time and effort attempting to try and get it to work, myself having spent over 80 hours (including my precious holiday time) trying to dig, scratch, research up old posts that say it works or someone has it working under such and such a configuration!
Did you use any of those 80 hours to RTFM at http://stunnel.mirt.net/static/stunnel.html ?
The documentation itself has folks claiming that it works and does not, which is really a bad practice. Why did you perpetuate this option in the first place?! I hope you see the importance and reason with my request and act immediately. ... Unless someone really really does have it working.
LOL: http://catb.org/~esr/faqs/smart-questions.html#id478549
Please make sure to read the whole http://catb.org/~esr/faqs/smart-questions.html before sending another post to a mailing list.
Best regards, Mike
Hi Mike,
Your reponse was in my spam folder, and I just realized it :-). It is good to hear that this configuration is ultimately possible -- but just not with out of the box configurations as far as my testing has shown. Therefore it is better if the documentation stated this.
Could you please try to be a bit more specific (e.g. in terms of your stunnel and kernel versions, configuration, logs, packet captures, etc.)?
I am using the most current versions to date for each software stacks. All use the same stunnel.conf file.
foreground = yes cert = /etc/stunnel/stunnel.pem sslVersion = all setuid = root setgid = root pid = /tmp/stunnel.pid socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 output = /var/log/stunnel.log
[http] accept = 443 connect = 80 transparent = yes
FreeBSD 8.1:
rpminit# stunnel -version stunnel 4.33 on amd64-portbld-freebsd8.1 with OpenSSL 0.9.8n 24 Mar 2010
rpminit# uname -a FreeBSD hostname 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Fri Jul 30 12:55:14 UTC 2010 root@hostname:/usr/obj/usr/src/sys/generic amd64
This stunnel version has been patched to support 'non-local bind'ng, see http://marc.info/?l=stunnel-users&m=129415990930730&w=2
CentOS : CentOS-5.5-x86_64-netinstall.iso:
[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 [root@localhost ~]# stunnel -version stunnel 4.15 on x86_64-redhat-linux-gnu with OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 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 = AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH key = /etc/stunnel/stunnel.pem session = 300 seconds TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds verify = none [root@localhost ~]#
[root@localhost ~]# iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables v1.3.5: Couldn't load match `socket':/lib64/iptables/libipt_socket.so: cannot open shared object file: No such file or directory
Try `iptables -h' or 'iptables --help' for more information. [root@localhost ~]#
Ubuntu : mini.iso Ubuntu 10.10 "Maverick Meerkat" Minimal CD 15.6MB (MD5: 3d9f096398991ed1eaa9ff32128e199a, SHA1: ea621a169b55d4c759f19600fea78e4ba7b83ba4) https://help.ubuntu.com/community/Installation/MinimalCD
foo@ubuntu:~$ uname -a Linux ubuntu 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC 2010 x86_64 GNU/Linux foo@ubuntu:~$ dpkg -s stunnel
Package: stunnel Status: install ok installed Priority: extra Section: net Installed-Size: 56 Maintainer: Ubuntu Developers [email protected] Architecture: all Source: stunnel4 Version: 3:4.29-1 Depends: stunnel4 (>= 3:4.20-3) Description: dummy upgrade package stunnel version 3 has been removed from Debian. This is a dummy package to ease upgrading to stunnel4. . You may safely remove this package after the upgrade. Original-Maintainer: Luis Rodrigo Gallardo Cruz [email protected] Homepage: http://www.stunnel.org/
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 ...
root@ubuntu:/etc/stunnel# iptables -t mangle -N DIVERT root@ubuntu:/etc/stunnel# iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT root@ubuntu:/etc/stunnel# iptables -t mangle -A DIVERT -j MARK --set-mark 1 root@ubuntu:/etc/stunnel# iptables -t mangle -A DIVERT -j ACCEPT root@ubuntu:/etc/stunnel# ip rule add fwmark 1 lookup 100 root@ubuntu:/etc/stunnel# ip route add local 0.0.0.0/0 dev lo table 100 root@ubuntu:/etc/stunnel# echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter root@ubuntu:/etc/stunnel# /etc/init.d/stunnel4 start 2011.01.07 13:29:34 LOG7[990:140669015152384]: http accepted FD=14 from 192.168.103.69:40886
2011.01.07 13:29:34 LOG7[990:140669015144192]: http started 2011.01.07 13:29:34 LOG7[990:140669015144192]: FD 14 in non-blocking mode 2011.01.07 13:29:34 LOG7[990:140669015144192]: TCP_NODELAY option set on local socket 2011.01.07 13:29:34 LOG7[990:140669015144192]: Waiting for a libwrap process 2011.01.07 13:29:34 LOG7[990:140669015144192]: Acquired libwrap process #0 2011.01.07 13:29:34 LOG7[990:140669015144192]: Releasing libwrap process #0 2011.01.07 13:29:34 LOG7[990:140669015144192]: Released libwrap process #0 2011.01.07 13:29:34 LOG7[990:140669015144192]: http permitted by libwrap from 192.168.103.69:40886 2011.01.07 13:29:34 LOG5[990:140669015144192]: http accepted connection from 192.168.103.69:40886 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): before/accept initialization 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): SSLv3 read client hello A 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): SSLv3 write server hello A 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): SSLv3 write certificate A 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): SSLv3 write server done A 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): SSLv3 flush data 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): SSLv3 read client key exchange A 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): SSLv3 read finished A 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): SSLv3 write change cipher spec A 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): SSLv3 write finished A 2011.01.07 13:29:34 LOG7[990:140669015144192]: SSL state (accept): SSLv3 flush data 2011.01.07 13:29:34 LOG7[990:140669015144192]: 2 items in the session cache 2011.01.07 13:29:34 LOG7[990:140669015144192]: 0 client connects (SSL_connect()) 2011.01.07 13:29:34 LOG7[990:140669015144192]: 0 client connects that finished 2011.01.07 13:29:34 LOG7[990:140669015144192]: 0 client renegotiations requested 2011.01.07 13:29:34 LOG7[990:140669015144192]: 2 server connects (SSL_accept()) 2011.01.07 13:29:34 LOG7[990:140669015144192]: 2 server connects that finished 2011.01.07 13:29:34 LOG7[990:140669015144192]: 0 server renegotiations requested 2011.01.07 13:29:34 LOG7[990:140669015144192]: 0 session cache hits 2011.01.07 13:29:34 LOG7[990:140669015144192]: 0 external session cache hits 2011.01.07 13:29:34 LOG7[990:140669015144192]: 0 session cache misses 2011.01.07 13:29:34 LOG7[990:140669015144192]: 0 session cache timeouts 2011.01.07 13:29:34 LOG6[990:140669015144192]: SSL accepted: new session negotiated 2011.01.07 13:29:34 LOG6[990:140669015144192]: Negotiated ciphers: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 2011.01.07 13:29:34 LOG7[990:140669015144192]: FD 15 in non-blocking mode 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 2011.01.07 13:29:44 LOG5[990:140669015144192]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2011.01.07 13:29:44 LOG7[990:140669015144192]: http finished (0 left)
Did you use any of those 80 hours to RTFM at http://stunnel.mirt.net/static/stunnel.html ?
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
"References for 2.4 kernel that say it's not possible..."
"Reference for 2.4 kernel that say it is possible..."
Would it be of best use to update this document for only the current state of the art kernel versions, and therefore remove references to 2.4 kernels? The confusion led me to hope that I could possibly get it working.
If out of the box transparent mode does not function, but requires non - portable modification, can you provide this code? One possible option is to upload a VM image that demonstrates.
If it is non-trivial and out of scope, it would be better to update the document with this information or provide further clarification as to this effect. Given that someone has accomplished the goal, a complete end to end solution is what really needs to be explained.
Best regards, OSC
-----Original Message----- From: Michal Trojnara [email protected] To: [email protected] Sent: Fri, Jan 7, 2011 3:41 am Subject: Re: [stunnel-users] RFC: purge use of keyword 'transparent'
Dear Oscar,
"Oscar Usifer" [email protected] wrote:
After searching, installing various (in the 2.6 family), e.g. CentOS, Ubuntu, and so on, I have not been able to get transparent proxy working at all.
LOL: http://catb.org/~esr/faqs/smart-questions.html#id479555
Could you please try to be a bit more specific (e.g. in terms of your stunnel and kernel versions, configuration, logs, packet captures, etc.)?
As such since it the function does not work, and there is great debate as to whether it ever worked, I would like to propose that this keyword and reference to its function be discarded entirely. This will save many folks a great deal of time and effort attempting to try and get it to work, myself having spent over 80 hours (including my precious holiday time) trying to dig, scratch, research up old posts that say it works or someone has it working under such and such a configuration!
Did you use any of those 80 hours to RTFM at http://stunnel.mirt.net/static/stunnel.html ?
The documentation itself has folks claiming that it works and does not, which is really a bad practice. Why did you perpetuate this option in the first place?!
I hope you see the importance and reason with my request and act immediately. ... Unless someone really really does have it working.
LOL: http://catb.org/~esr/faqs/smart-questions.html#id478549
Please make sure to read the whole http://catb.org/~esr/faqs/smart-questions.html before sending another post to a mailing list.
Best regards, Mike =
_______________________________________________
stunnel-users mailing list
Follow up on FreeBSD's traffic and syndrome looks like :
With stunnel's transparent set option traffic looks like :
19:31:34.162337 IP 192.168.103.69.52671 > 127.0.0.1.80: Flags [S], seq 2050938762, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 7437993 ecr 0], length 0 19:31:37.153079 IP 192.168.103.69.52671 > 127.0.0.1.80: Flags [S], <snip>.. 19:31:40.351804 IP 192.168.103.69.52671 > 127.0.0.1.80: Flags [S], <snip> .. 19:31:43.550543 IP 192.168.103.69.52671 > 127.0.0.1.80: Flags [S], seq 2050938762, win 65535, options [mss 16344,sackOK,eol], length 0
...
2011.01.07 19:32:55 LOG7[6662:34378629568]: Service ssh_proxy accepted FD=13 from 192.168.103.69:52673 2011.01.07 19:32:55 LOG7[6662:34379125184]: Service ssh_proxy started 2011.01.07 19:32:55 LOG7[6662:34379125184]: FD=13 in non-blocking mode 2011.01.07 19:32:55 LOG7[6662:34379125184]: Option TCP_NODELAY set on local socket 2011.01.07 19:32:55 LOG7[6662:34379125184]: Waiting for a libwrap process 2011.01.07 19:32:55 LOG7[6662:34379125184]: Acquired libwrap process #0 2011.01.07 19:32:55 LOG7[6662:34379125184]: Releasing libwrap process #0 2011.01.07 19:32:55 LOG7[6662:34379125184]: Released libwrap process #0 2011.01.07 19:32:55 LOG7[6662:34379125184]: Service ssh_proxy permitted by libwrap from 192.168.103.69:52673 2011.01.07 19:32:55 LOG5[6662:34379125184]: Service ssh_proxy accepted connection from 192.168.103.69:52673 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): before/accept initialization 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): SSLv3 read client hello A 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): SSLv3 write server hello A 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): SSLv3 write certificate A 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): SSLv3 write server done A 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): SSLv3 flush data 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): SSLv3 read client key exchange A 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): SSLv3 read finished A 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): SSLv3 write change cipher spec A 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): SSLv3 write finished A 2011.01.07 19:32:55 LOG7[6662:34379125184]: SSL state (accept): SSLv3 flush data 2011.01.07 19:32:55 LOG7[6662:34379125184]: 1 items in the session cache 2011.01.07 19:32:55 LOG7[6662:34379125184]: 0 client connects (SSL_connect()) 2011.01.07 19:32:55 LOG7[6662:34379125184]: 0 client connects that finished 2011.01.07 19:32:55 LOG7[6662:34379125184]: 0 client renegotiations requested 2011.01.07 19:32:55 LOG7[6662:34379125184]: 1 server connects (SSL_accept()) 2011.01.07 19:32:55 LOG7[6662:34379125184]: 1 server connects that finished 2011.01.07 19:32:55 LOG7[6662:34379125184]: 0 server renegotiations requested 2011.01.07 19:32:55 LOG7[6662:34379125184]: 0 session cache hits 2011.01.07 19:32:55 LOG7[6662:34379125184]: 0 external session cache hits 2011.01.07 19:32:55 LOG7[6662:34379125184]: 0 session cache misses 2011.01.07 19:32:55 LOG7[6662:34379125184]: 0 session cache timeouts 2011.01.07 19:32:55 LOG6[6662:34379125184]: SSL accepted: new session negotiated 2011.01.07 19:32:55 LOG6[6662:34379125184]: Negotiated ciphers: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 2011.01.07 19:32:55 LOG7[6662:34379125184]: FD=14 in non-blocking mode 2011.01.07 19:32:55 LOG6[6662:34379125184]: connect_blocking: connecting 127.0.0.1:80 2011.01.07 19:32:55 LOG5[6662:34379125184]: connect_blocking: connected 127.0.0.1:80 2011.01.07 19:32:55 LOG5[6662:34379125184]: Service ssh_proxy connected remote server from 127.0.0.1:30326 2011.01.07 19:32:55 LOG7[6662:34379125184]: Remote FD=14 initialized 2011.01.07 19:32:55 LOG7[6662:34379125184]: Option TCP_NODELAY set on remote socket 2011.01.07 19:32:58 LOG7[6662:34379125184]: SSL socket closed on SSL_read 2011.01.07 19:32:58 LOG7[6662:34379125184]: Socket write shutdown 2011.01.07 19:32:58 LOG5[6662:34379125184]: Connection closed: 0 bytes sent to SSL, 0 bytes sent to socket 2011.01.07 19:32:58 LOG7[6662:34379125184]: Service ssh_proxy finished (0 left)
Without transparent, traffic flows fine, and looks like :
19:32:55.883404 IP 127.0.0.1.30326 > 127.0.0.1.80: Flags [S], seq 2147354729, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 7446169 ecr 0], length 0 19:32:55.883575 IP 127.0.0.1.80 > 127.0.0.1.30326: Flags [S.], seq 2770470513, ack 2147354730, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 1229815108 ecr 7446169], length 0 19:32:55.883589 IP 127.0.0.1.30326 > 127.0.0.1.80: Flags [.], ack 1, win 8960, options [nop,nop,TS val 7446169 ecr 1229815108], length 0
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
I will follow up with Ubuntu.
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?
In the words of Frank Herbert, 'Gods below!'. :D
Thanks
-
Markus Borst -
Michal Trojnara -
oscaruser＠programmer.net