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

[Yves Rutschle]

On Tue, Jul 10, 2012 at 09:51:10AM +0200, Kai wrote:
> #  /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, how long does OpenVPN take to create a
connection on average?

> 2. The sslh server output is like this:
> 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
            ^^^^^
This was forwarded to ssh, so I guess the OpenVPN client
took a very long time (>10s) before sending its first
packet?

If that's not the case and OpenVPN does indeed send its
first packet pretty quickly, then we may have a detection
problem: could you capture the beginning of a connection
with tcpdump:

tcpdump -X -s 0 tcp port 443

> My openvpn client says:
> _______________________
> ############# not working
[...]
> 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...]

Well, yeah, it's talking to sshd :-)

> 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 wouldn't think so. The 3 alternatives I can think of are:

- OpenVPN client takes more than 10s "most of the time"
  (hence it works once in a while)
- The first packet gets fragmented in the network in a way
  that the OpenVPN probe code can't process
- OpenVPN probe code isn't quite right and is wrong in some
  cases.
 
> 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

Yup, it's receiving connections from the OpenVPN client.

> 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. 

Not yet, I don't think that would teach us much so far.

Y.