Hi,
I have a couple of questions regarding failover with stunnel:
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.
The following rule doesn't work, because the cert and key parameters are overwritten, but it shows what I would like to achieve:
[failover] accept = 127.0.0.1:4441 http://127.0.0.1:4441/ cert = cert_1.cert key = key_1.pem connect = server-1:1234 cert = cert_2.cert key = key_2.pem connect = server-2:1234
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?
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 http://127.0.0.1:4441/; PROXY 127.0.0.1:4442 http://127.0.0.1:4442/; PROXY 127.0.0.1:4443 http://127.0.0.1:4443/;". However, when one of the remote server is down (i.e. server-1), it is not easily detected by web-browsers (Chrome does not seem to detect it well), and so instead of switching to the next PROXY, it simply dies on the first one. If the port 4441 relative to server-1 (which is unavailable) was closed, then the webrowser could easily detect it and switch to the second server with port 4442.
3. Is there another way to tweak stunnel behavior when a remote server is down?
I'm thinking about a couple of things, like being able to switch to a different rule set:
[failover1] accept = 127.0.0.1:4441 http://127.0.0.1:4441/ cert = cert_1.cert key = key_1.pem connect = server-1:1234 connect = 127.0.0.1:4442 http://127.0.0.1:4442/ ; This is failover2
[failover2] accept = 127.0.0.1:4442 http://127.0.0.1:4442/ cert = cert_2.cert key = key_2.pem connect = server-2:1234
Or maybe there are some options that I'm not aware of to timeout connections more efficiently: so that Chrome (or other clients using HTTP proxies) will immediately know that stunnel cannot connect to the remote server and so that the proxy is down.
Thank you for your help.
Cheers,
Thireus.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 15.11.2015 11:58, Thireus wrote:
- 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.
- 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.
- 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
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 ([email protected] mailto:[email protected]), IT Security Engineer Consultant. http://blog.thireus.com http://blog.thireus.com/
Le 15 nov. 2015 à 19:58, Michal Trojnara [email protected] a écrit :
Signé partie PGP On 15.11.2015 11:58, Thireus wrote:
- 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.
- 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.
- 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 [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-----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 ([email protected] mailto:[email protected]), IT Security Engineer Consultant. http://blog.thireus.com http://blog.thireus.com/
Le 15 nov. 2015 à 19:58, Michal Trojnara <[email protected] mailto:[email protected]> a écrit :
Signé partie PGP On 15.11.2015 11:58, Thireus wrote:
- 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.
- 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.
- 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 [email protected] mailto:[email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-
Michal Trojnara -
Thireus