sslh-select hangs when connecting towards an unresponsive server

[yrutschle]

Use case: sslh forwards incoming HTTPS to a local LXC, which is not started. Connection towards the LXC hangs (e.g. telnet prints Trying 192.168.0.3... then waits for a long time).

sslh also hangs, which means no other connection are serviced.

[fdellwing]

We face the same issue in 1.21:

May 27 14:42:26 mbCONNECT24 sslh-select[6563]: http:connection from 66.19.x.x:41347 to 198.50.162.21:4443 forwarded from 66.19.x.x:41347 to 192.168.0.181:443
May 27 14:44:35 mbCONNECT24 sslh-select[6563]: forward to openvpn failed:connect: Connection timed out
[...]
May 27 14:44:48 mbCONNECT24 sslh-select[6563]: http:connection from 166.159.x.x:41527 to 198.50.162.21:4443 forwarded from 166.159.x.x:41527 to 192.168.0.181:443
May 27 14:46:58 mbCONNECT24 sslh-select[6563]: forward to openvpn failed:connect: Connection timed out
[...]
May 27 14:49:30 mbCONNECT24 sslh-select[6563]: tls:connection from 165.225.x.x:13373 to 198.50.162.21:4443 forwarded from 165.225.x.x:13373 to 192.168.0.181:443
May 27 14:51:41 mbCONNECT24 sslh-select[6563]: forward to openvpn failed:connect: Connection timed out

As you can see, the server is always unresponsive for about 130seconds. This is a big problem for us, as we are now unable to use sslh-select at all.

Any idea how to solve this issue in sslh?

[yrutschle]

Ok, I had a quick look.
The issue is that upon calling accept(2) in common.c:connect_addr(), the file descriptor is blocking.
The patch attached would fix that, but for some reason the file descriptors that hang, hang... forever, apparently.
So I can't quite commit this, I'll investigate further.
non_block.zip

[yrutschle]

Ok, this commit should work. It may fail if the server name resolves to several addresses, one of which hangs while the others don't, as sslh will stop trying with the first connect(2) that returns (e.g. "target.example.com" resolves to an IPv4 and IPv6; sslh connects to the IPv4, and connect() returns: it won't even try to connect to the IPv6. Before, it tried all adresses with connect() blocking, which means it had an answer from the remote server). I don't think that would be a big issue but I could be wrong.

I expect the commit should apply to 1.21c straightfowardly, but I didn't try it.

[fdellwing]

We will try the change. Name resolution is not a problem for us, as we only use local addresses as target.

Thanks a lot for your work 👍