[sslh] SSLH seems to forward OpenVPN connection to SSH port

[Kai]

Hello Yves,

There is something really strange happening:

1. When using the following start string of sshl:

#  /usr/local/sbin/sslh -t 10 -u sslh -p my.external.ip:443 --ssh 
127.0.0.1:23022 --openvpn 127.0.0.1:1194 -P /var/run/sslh.pid -f -v # 
--ssl 127.0.0.1:443

It takes me 2 minutes or even more = many X0 retries to get a 
connection. Some times it is quicker some times faster.

Without sslh I only need one try.

2. The sslh server output is like this:

The first example is failing, the second not:

_______________________
accepted fd 4
**** writing defered on fd -1
connecting to localhost:23022 family 2 len 16
connection from xxx.t-dialin.net:57684 to localhost.localdomain:https 
forwarded from localhost:45736 to localhost:23022
flushing defered data to fd 3
client socket closed
connection closed down
accepted fd 4
**** writing defered on fd -1
connecting to localhost:openvpn family 2 len 16
connection from xxx.t-dialin.net:57686 to localhost.localdomain:https 
forwarded from localhost:42894 to localhost:openvpn
flushing defered data to fd 3
_______________________

My openvpn client says:
_______________________
############# not working
Jul 09 23:47:35: Connection reset, restarting [0]
Jul 09 23:47:35: SIGUSR1[soft,connection-reset] received, process restarting
Jul 09 23:47:35: NOTE: OpenVPN 2.1 requires '--script-security 2' or 
higher to call user-defined scripts or executables
Jul 09 23:47:35: LZO compression initialized
Jul 09 23:47:35: WARNING: normally if you use --mssfix and/or 
--fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Jul 09 23:47:35: TUN/TAP device /dev/tun0 opened
Jul 09 23:47:35: /sbin/ifconfig tun0 delete
Jul 09 23:47:35: NOTE: Tried to delete pre-existing tun/tap instance -- 
No Problem if failure
Jul 09 23:47:35: /sbin/ifconfig tun0 10.9.9.2 10.9.9.1 mtu 1400 netmask 
255.255.255.255 up
Jul 09 23:47:35: Attempting to establish TCP connection with 
my.external.ip:443 [nonblock]
Jul 09 23:47:36: TCP connection established with my.external.ip:443
Jul 09 23:47:36: TCPv4_CLIENT link local: [undef]
Jul 09 23:47:36: TCPv4_CLIENT link remote: my.external.ip:443
Jul 09 23:47:36: WARNING: Bad encapsulated packet length from peer 
(21331), which must be > 0 and <= 1447 -- please ensure that --tun-mtu 
or --link-mtu is equal on both peers -- this condition could also 
indicate a possible active attack on the TCP link -- [Attempting restart...]
############# working
Jul 09 23:47:36: Connection reset, restarting [0]
Jul 09 23:47:36: SIGUSR1[soft,connection-reset] received, process restarting
Jul 09 23:47:37: NOTE: OpenVPN 2.1 requires '--script-security 2' or 
higher to call user-defined scripts or executables
Jul 09 23:47:37: LZO compression initialized
Jul 09 23:47:37: WARNING: normally if you use --mssfix and/or 
--fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Jul 09 23:47:37: TUN/TAP device /dev/tun0 opened
Jul 09 23:47:37: /sbin/ifconfig tun0 delete
Jul 09 23:47:37: NOTE: Tried to delete pre-existing tun/tap instance -- 
No Problem if failure
Jul 09 23:47:37: /sbin/ifconfig tun0 10.9.9.2 10.9.9.1 mtu 1400 netmask 
255.255.255.255 up
Jul 09 23:47:37: Attempting to establish TCP connection with 
my.external.ip:443 [nonblock]
Jul 09 23:47:38: TCP connection established with my.external.ip:443
Jul 09 23:47:38: TCPv4_CLIENT link local: [undef]
Jul 09 23:47:38: TCPv4_CLIENT link remote: my.external.ip:443
Jul 09 23:47:38: Peer Connection Initiated with my.external.ip:443
Jul 09 23:47:39: Initialization Sequence Completed
_______________________

You can ignore 'WARNING: normally if you use --mssfix and/or --fragment, 
you should also set --tun-mtu 1500 (currently it is 1400)' whatever MTU 
size I set there is no difference in the behavior.

Can it be that SSLH buffers the data for too long and than sending too 
many data at once 'WARNING: Bad encapsulated packet length from peer 
(21331), which must be > 0 and <= 1447 -- please ensure that --tun-mtu 
or --link-mtu is equal on both peers -- this condition could also 
indicate a possible active attack on the TCP link -- [Attempting 
restart...]' might indicate.

I also see the last sshd error message in /var/log/auth.log exactly 
at 23:47:36 which is before the working attempt starts.

Jul  9 23:47:35 sshd[2836]: Bad protocol version identification '' from 
127.0.0.1
Jul  9 23:47:36 sshd[2838]: Bad protocol version identification '' from 
127.0.0.1

3. I coul not find any additional debug information I could see in the 
sources that I could turn on other than -v. I have created some strace 
outputs as well but do not like to send them via a this mailing list for 
security reasons. But I can share them directly with you if you think it 
helps analyzing the issue.

Best regards,
Kai


Am 09.07.2012 um 09:45 schrieb Kai:

> Hallo Yves,
>
> Thank you very much. I have changed it on my server and I will try it 
> out this evening when I have the chance to test.
>
> Best regards,
> Kai
>
> Am 06.07.2012 15:19, schrieb Yves Rutschle:
>> You can try increasing the timeout that switches to sslh. The default 
>> is 2s and is known to be too fast for openvpn.
>
> _______________________________________________
> sslh mailing list
> sslh at rutschle.net
> http://rutschle.net/cgi-bin/mailman/listinfo/sslh