OpenVPN tun interface over TCP and security considerations

[mad_ady]

Hello all,
I've setup on OpenVPN server on my AsusWRT router running RMerlin's firmware and I'm pretty happy with it - thanks for the effort.

However, there are two things that I'm not sure about:
1. I have enabled OpenVPN over TCP (using port 445) so that it is accessible from behind restrictive firewalls that do layer 7 inspection. However, I wonder if I've killed performance, because I'm tunnelling TCP over TCP (http://sites.inka.de/bigred/devel/tcp-tcp.html) and I expect problems when the traffic encounters congestion. I haven't done any performance tests (lack of time), but does openvpn's tun implementation over TCP notify the upper layers of packet loss, or not?
I will consider going over UDP, but can anyone suggest a UDP port that is likely open on most firewalls and where encrypted traffic can pass inspection? I doubt going over port 53 would work...

2. Up to this point I had used ssh tunnels to get into my network and I protected the ssh server with a port-knocker. I would send the correct 3 packet sequence and the port-knocker would open the (non-standard) port from my current IP. It's security by obscurity, I know, but it protects you from all the scanners from China (no offense!). Should I employ a similar technique for OpenVPN? Can a client connect without the ovpn file? I am using long random passwords, but I'd like the service to be as low-profile as possible.
So, my question is - if I leave it as is, how can an attacker know it's talking to an OpenVPN isntead of a HTTPS server (scanning for banners with nmap shows nothing)?

 

[ColinTaylor]

I haven't done any performance tests (lack of time)

Then I'd suggest you do do some performance tests. I'd guess that if there was a major problem with OpenVPN performance in the 15 years since that article was written there'd be a lot of people complaining about it.

 

[mad_ady]

I will when I get a bit of time. However I need to do some tests inside the same ISP - my current use case is over an inter-ISP congested link and would probably not show much difference (I get about 12Mbps).
What about #2? Do I need to worry about brute-force connection attempts? I know that with ssh you'll start seeing in your auth.log lots of attempts after a while. I worry because I'm not monitoring the router's logs so brute-force would go unnoticed.

 

[RMerlin]

Very few will try to hack through an OpenVPN server because it usually requires having the appropriate certificates - not something they can brute force, unlike SSH which is often configured with only password-based authentication.

 

[sfx2000]

Very few will try to hack through an OpenVPN server because it usually requires having the appropriate certificates - not something they can brute force, unlike SSH which is often configured with only password-based authentication.

The script kiddies like OpenSSH as a target since it is TCP based, so it's fast to scan against - but also consider than OpenSSH is fairly secure - even with username/passwords, nothing is sent over the wire - it uses DH Key Exchange even outside of certificates - and there's always the option of using certs in any case.

OpenVPN in UDP mode, which is the default - scanners tend to stay away from it, as UDP port scans are extremely time and resource intensive compared to TCP scanning -

And as RMerlin suggests, it non-trivial to even try brute forcing... most compromises there would be more due to errors in configuration more than anything else, and OpenVPN is pretty hard to mess up - but to err is human, and humans do make mistakes from time to time...

Not to say it couldn't be done, but there are lower hanging fruit where potential results can be had with much less effort.

 

[mad_ady]

Thank you for your inputs.
I've selected user/password authentication and I see that the ovpn file has only a "ca" certificate generated. So, I expect this is used to check the authenticity of the VPN server only - which an attacker wouldn't need - it could always trust certificates signed by an unknown CA.

I've seen that the default option generates an ovpn with more certificates inside, which seems much safer, but I'd have to reuse the certificates on multiple mobile clients and in the event of having a client stolen I need to revoke the keys for everyone. I would have been nicer to have independent keys for each user, but since the public-private key pair is unique, I guess the server would need to have multiple public keys...