Hi!
After using stunnel on several freebsd boxes i decided to try it out on my mailserver..
Unfortunately it silently died after first connection.. ( and with exitcode=0 )
debug = 7
Nothing more in the log than startup + a line about a incomming connection on port 9143.. ( where i put my incomming imap )
Nothing in any log on the box..
Ok.. It might be my openssl freebsd version or stunnel version so i started to upgrade everything.. Freebsd 4.4 -> 4.11 stunnel 4.05 -> 4.11 etc..
Well did it work.. Nop..;-)
Finally i found out after tryin ktrace that the problem was that the tcpwrapper code killed me..
That's ok but there where no logging at all that the tcpwrapper silently decided that i was comming from a blocked host..
It's up now without tcpwrapper enabled and works perfect..;-)
Is there any possibility to have stunnel to say something about tcpwrapper problems..;-)
And not just die..;-)
Regards
/Uffe
On Fri, 14 Oct 2005, Uffe Vedenbrant wrote:
Is there any possibility to have stunnel to say something about tcpwrapper problems..;-)
I don't really understand it as I made this config error a couple of times myself but it was nicely logged. Then again, this last happened to me with 3.x code so...
Jan
Jan Meijer wrote:
On Fri, 14 Oct 2005, Uffe Vedenbrant wrote:
Is there any possibility to have stunnel to say something about tcpwrapper problems..;-)
I don't really understand it as I made this config error a couple of times myself but it was nicely logged. Then again, this last happened to me with 3.x code so...
Was it logged by tcpwrapper (libwrap) or by stunnel that logged your problems?
/Uffe
On Fri, 14 Oct 2005, Uffe Vedenbrant wrote:
Jan Meijer wrote:
On Fri, 14 Oct 2005, Uffe Vedenbrant wrote:
Is there any possibility to have stunnel to say something about tcpwrapper problems..;-)
I don't really understand it as I made this config error a couple of times myself but it was nicely logged. Then again, this last happened to me with 3.x code so...
Was it logged by tcpwrapper (libwrap) or by stunnel that logged your problems?
I wouldn't know anymore. Would have to test/check the code, but without doubt Mike already knows the answer.
Jan
Note that stunnel died completely.. I.e. not just denied the new connection..
It might be something with my environment of course.
FreeBSD 4.4 , Stunnel 4.05 ( died ) FreeBSD 4.11-p12 , Stunnel 4.11 ( died )
Disabled libwrap and everything worked fine..;-)
If this is the intended action then there is a good possibility for killing stunnel daemons out there.. i.e. if someone sets up tcpwrap to only allow some connections....
/Uffe
Jan Meijer wrote:
On Fri, 14 Oct 2005, Uffe Vedenbrant wrote:
Jan Meijer wrote:
On Fri, 14 Oct 2005, Uffe Vedenbrant wrote:
Is there any possibility to have stunnel to say something about tcpwrapper problems..;-)
I don't really understand it as I made this config error a couple of times myself but it was nicely logged. Then again, this last happened to me with 3.x code so...
Was it logged by tcpwrapper (libwrap) or by stunnel that logged your problems?
I wouldn't know anymore. Would have to test/check the code, but without doubt Mike already knows the answer.
Jan
Finally found why/where stunnel silently dies for me..;-)
In FreeBSD there is a default "catch-all" entry in hosts.allow that stunnel does not like if there is any missing service entries the first time stunnel is started...
I.e. one needs to have all stunnel.conf service entries configured in hosts.allow, in my case
SMTPPORT25 : ALL : allow IMAPPORT143 : ALL : allow
needed to be there...
The "catch-all" looks as below.. --------------
# The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h."
-------------
This causes stunnel to silently die with exit code 0..
If this is removed/changed to
----------------- ALL : ALL : deny -----------------
everything works as expected..
I.e. libwrap will complain about unauthorized access and keep on running, not just die without any logging at all..
I really cannot say however if this is a stunnel or libwrap bug/feature.. I.e. is stunnel to sensitive of what it gets back from libwrap or is libwrap sending more data than needed back to stunnel..
/Uffe
Jan Meijer wrote:
On Fri, 14 Oct 2005, Uffe Vedenbrant wrote:
Is there any possibility to have stunnel to say something about tcpwrapper problems..;-)
I don't really understand it as I made this config error a couple of times myself but it was nicely logged. Then again, this last happened to me with 3.x code so...
Jan
"Uffe Vedenbrant" [email protected] wrote:
I.e. libwrap will complain about unauthorized access and keep on running, not just die without any logging at all..
I really cannot say however if this is a stunnel or libwrap bug/feature.. I.e. is stunnel to sensitive of what it gets back from libwrap or is libwrap sending more data than needed back to stunnel..
Libwrap hosts_access(3) manual claims: hosts_access() consults the access control tables described in the hosts_access(5) manual page. When internal endpoint information is available, host names and client user names are looked up on demand, using the request structure as a cache. hosts_access() returns zero if access should be denied.
On the other hand hosts_options(5) claims: twist shell_command Replace the current process by an instance of the specified shell command, after performing the %<letter> expansions described in the hosts_access(5) manual page. Stdin, stdout and stderr are connected to the client process. This option must appear at the end of a rule.
In this case hosts_access *does not return at all*. 8-)
Good news! I've just modified stunnel to run libwrap as a separate process. Here is the beta version. It should work fine with twist option. ftp://stunnel.mirt.net/stunnel/stunnel-4.13b1.tar.gz
Best regards, Mike
Hello Michal,
Are there any plans to introduse the UDP support in stunnel via OpenSSL's DTLS?
Thank you in advance.
Tony.
[email protected] wrote:
Are there any plans to introduse the UDP support in stunnel via OpenSSL's DTLS?
No plans for that feature (unless I can find a sponsor for it).
Best regards, Mike
Great!
It didn't die.. I hope that this does not cause high load on servers accepting a high number of connects per second..
/Uffe
Michal Trojnara wrote:
"Uffe Vedenbrant" [email protected] wrote:
I.e. libwrap will complain about unauthorized access and keep on running, not just die without any logging at all..
I really cannot say however if this is a stunnel or libwrap bug/feature.. I.e. is stunnel to sensitive of what it gets back from libwrap or is libwrap sending more data than needed back to stunnel..
Libwrap hosts_access(3) manual claims: hosts_access() consults the access control tables described in the hosts_access(5) manual page. When internal endpoint information is available, host names and client user names are looked up on demand, using the request structure as a cache. hosts_access() returns zero if access should be denied.
On the other hand hosts_options(5) claims: twist shell_command Replace the current process by an instance of the specified shell command, after performing the %<letter> expansions described in the hosts_access(5) manual page. Stdin, stdout and stderr are connected to the client process. This option must appear at the end of a rule.
In this case hosts_access *does not return at all*. 8-)
Good news! I've just modified stunnel to run libwrap as a separate process. Here is the beta version. It should work fine with twist option. ftp://stunnel.mirt.net/stunnel/stunnel-4.13b1.tar.gz
Best regards, Mike
stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users
-
Jan Meijer -
Michal Trojnara -
rz1a＠mail.ru -
Uffe Vedenbrant