[stunnel-users] Failover behavior with stunnel

[Michal Trojnara]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Thireus,

I'm glad you got it working.

Did you consider sharing your monitoring daemon with the community?

Best regards,
	Mike

On 29.11.2015 15:07, Thireus wrote:
> Hi Michal,
> 
> Thank you for the answer.
> 
> I found a solution for this using local port forwarding. What I do
> now is that I monitor my individual tunnels to check if they are
> alive. When one is dead I just have to change the port forward to
> the next stunnel entry.
> 
> I use netcat to check the connection availability as follow:
> 
> nc -z -x 127.0.0.1:$STUNNEL_PORT1 -X connect $DISTANT_SERVER $PORT
> 
> Under OS X, since 10.10 port forwarding is managed with the pfctl 
> utility (on other linux distro we can use iptables):
> 
> echo "rdr pass inet proto tcp from 127.0.0.1 to 127.0.0.1 port
> $FAILOVER_PORT -> 127.0.0.1 port $STUNNEL_PORT1" | pfctl -ef -
>> /dev/null 2>&1
> 
> In case $STUNNEL_PORT1 is down or doesn't provide Internet access,
> I just switch to $STUNNEL_PORT2 and push the port forwarding rule
> with that port entry.
> 
> I wrote a daemon that monitors all my stunnel ports and check if
> they have Internet access, my PAC RETURN rules remain the same
> (they use my $FAILOVER_PORT), I just shifted stunnel ports to
> another location and use port forwarding to reach the stunnel
> entries that are alive.
> 
> It's working great so far.
> 
> Cheers,
> 
> Thireus (thireus at gmail.com <mailto:thireus at gmail.com>), IT Security
> Engineer Consultant. http://blog.thireus.com
> <http://blog.thireus.com/>
> 
>> Le 15 nov. 2015 à 19:58, Michal Trojnara
>> <Michal.Trojnara at mirt.net <mailto:Michal.Trojnara at mirt.net>> a
>> écrit :
>> 
>> Signé partie PGP On 15.11.2015 11:58, Thireus wrote:
>>> 1. I would like to know if there is a way to use failover with
>>> two servers with two different set of TLS cert/key.
>> 
>> No.  Both client and server certificates are currently set way
>> before stunnel connects the target.
>> 
>> I guess what you really need is client certificate selection
>> based on the list of acceptable issuers sent by the stunnel
>> server, because each of your stunnel servers expects client
>> certificates issued by a separate CA.  Am I right?
>> 
>> Client certificate autoselection currently works on Windows with
>> the CAPI engine.  I have also added a new TODO item to implement
>> client certificate autoselection for certificates/keys stored in
>> PEM files: https://www.stunnel.org/sdf_todo.html
>> 
>> Alternatively, you may reconfigure your stunnel servers to
>> accept client certificates issued by the same CA.
>> 
>>> 2. On the same topic, I would like to know if there is an
>>> option that could open the local port (accept) only when the
>>> connection (connect) is established?
>> 
>> No.
>> 
>>> The problem I'm facing is that I use a PAC profile with
>>> failover on several stunnel entries: "return PROXY
>>> 127.0.0.1:4441; PROXY 127.0.0.1:4442; PROXY 127.0.0.1:4443;".
>> 
>> Did you mean: return "PROXY 127.0.0.1:4441; PROXY 127.0.0.1:4442;
>> PROXY 127.0.0.1:4443 "; ?
>> 
>> You are trying establish end-to-end failover across two (in fact 
>> three, including connection between the stunnel server and the
>> HTTP proxy) separate TCP connections.  It is not possible without
>> a heartbeat service.
>> 
>>> 3. Is there another way to tweak stunnel behavior when a
>>> remote server is down?
>> 
>> You could write a heartbeat service to periodically initiate
>> short connections to the remote services, and then reconfigure
>> stunnel accordingly.  Still, this is a crude workaround and not
>> the proper solution.
>> 
>> Best regards, Mike
>> 
>> 
>> _______________________________________________ stunnel-users
>> mailing list stunnel-users at stunnel.org
>> <mailto:stunnel-users at stunnel.org> 
>> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWXBhIAAoJEC78f/DUFuAUkfoQAIVBiuNrAhEPyWQlzUD1AIyo
fMsNnZxQqpXsJOs1IFfZuLKPG7MDlH5K9Ipc3OMZdWL38yywuELiNXKJa3f27Dz7
hldQL43L3WjlSwpyzq9qEjmxG+UFubM0wLL7DVLUiyu6UZGnFRP1W5Wg/KBXCGKn
fkabH23U9GrKONk1/u6rTPHELKt7ogYS94iv3vvOhuDesgaew+/yBt9midDmmqge
zHO+L74Xy4OJOYBXry5yvQAB6vzVjRdM0TOJkC0W3VjkL5VZTq48S2gali2lWu8O
AfFXi+1MsN1UwBtPYvL71v21HoSJSjQrHrWQ0+XASW9l63metBnyxT7G3ln5T7TX
9d01uO58LKM+o8+7NknhglJxb0rYidM1badg8a47bYvXjxAUadCXZ2ASGg9lhRJl
7nG5Oslo63BAb0L+noNS2bgyNEWK1w6g7z54R9USM9WwRHZcqENp0ibxiYqRiMOD
5n2s5F2Fs7Now/OmyzL6L41jPDmrImVNR39GcfntqlAGkOB8EhybLju8l5WdR77n
7Jk6DLtSAI4U6gQIe+2E97EhV0qILRYDRqT4USz1LEftD5HNabGxbiEXQRxcTve3
tYrdK/kkA7B9oVT7qbsrct7IhWE6aZpZZM8fEWQC2VkqFisyLfGd8k1ie3jX5Zvk
Ulpv9C8ucEagIvwXsWs4
=lKZ4
-----END PGP SIGNATURE-----