Block malicious OpenVPN connection attempts (fail2ban?)

Security
1

Hi,

I can see a lot of these in /var/log/messages:

Jan 15 18:06:58 ipfire openvpnserver[4176]: 95.173.165.227:47747 TLS: Initial packet from [AF_INET]95.173.165.227:47747, sid=6a22eb44 5adb63fe
Jan 15 18:07:01 ipfire openvpnserver[4176]: 95.173.165.227:4035 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jan 15 18:07:01 ipfire openvpnserver[4176]: 95.173.165.227:4035 TLS Error: TLS handshake failed
Jan 15 18:07:01 ipfire openvpnserver[4176]: 95.173.165.227:4035 SIGUSR1[soft,tls-error] received, client-instance restarting

As we don’t have any users in Turkey, I generally want to block attempts to access our OpenVPN that are continuously failing (not blocking Turkey).

On external systems, I would configure fail2ban to do this. Is there a best practice on how to achieve this with IPFire?

2

Hi larsen,
‘–tls-auth’ or in webinterface words spoken, TLS Channel Protection should also do the trick.

Best,

Erik

P.S.: Be aware that both sites need the static key and an appropriate entry in the configuration file.

3 Likes
3

Hi Erik,

thanks for the information. This creates some questions:

  1. Before activating that option, I would have to enter the static key in every client’s configuration. Is this correct?

  2. I assume that newly created client configs will automatically get the key. Correct?

  3. I didn’t see the changes from this patch in my current ovpnmain.cgi:
    [3/3] OpenVPN: Integrate TLS-Authentication and HMAC selection - Patchwork
    Is tls-crypt only available in IPFire 3?

  4. The doc reads a 2048 bit static key is responsible (which can be found under/var/ipfire/ovpn/certs).
    In which file exactly? ta.key it seems.

  5. Will the static key change when I activate “TLS Channel Protection”?

4

Hi Larsen,

  1. Yes, this is correct if you did not activate the TLS Channel Protection before distribution of the client packages but you want to distribute it afterwards. In the regular (configured) case, IPFire should do this for you by activating it…
  2. Yes this should also be the case but also the entry in client.ovpn should be made by IPFire.
  3. Oh, this has been never been merged :wink: but this should be per default ‘–tls-crypt’ instead of ‘–tls-auth’ ← but again, it has not been merged → ‘–tls-auth’ is avaliable :slight_smile: .
  4. If you have set it in the CGI you should have the static key in there, yes.
  5. No, it will be created.

Hope this helps a little.

Best,

Erik

2 Likes
5
  1. tls-crypt sounds like a better version of tls-auth, afaict. Will you try to get this merged?
  1. You’ve confused me a little bit =) → ta.key already exists even though tls-auth has never been activated before, afaik. So, this file will not be “re-created” when activating tls-auth, will it?
  1. What would be the best way to implement this in our ~30 user setup without causing a VPN downtime for users due to having incorrect client config? Will the following work?
  • Temporarily activate tlsauth for some minutes only, download a client package and spot the difference between old and new config
  • Manually add that difference to all clients’ configs
  • If everyone has their config patched, activate tlsauth for good

Potential problem: OpenVPN client might complain about having tls-auth configured, but server not using it. I suppose this won’t block the client from connecting.

6
  1. IMO it is. I am not able to merge here something :slight_smile: .
    6?. Yes, if a key is presant no other key will be created.
  2. Afterward is this difficult. A good configuration for your environment before might be the best. Downtime depends then on it → is fail2ban better for your environment ?! Currently not sure about, since it is also not available on IPFire.

Best,

Erik

7

Unfortunately, my time machine is broken :wink:
Do you think that the proposed way might work?

8

Hi @larsen ,
no problem mine is currently broken too :wink: .
According to you problem, --tls-auth should work. In here Hardening OpenVPN Security | OpenVPN (in the IPFire wiki a little rudimentary of course too) you can read a little more about this kind of hardening.

Spoken about the downtime: I think you can manage this may easy. 1) After your office is closed, activate the “TLS Channel Protection” in the WUI and create all packages. 2) Deactivate the “TLS Channel Protection” again to be able to use the VPN connection as before. 3) Distribute the packages while working time, may also via VPN… 4) Set a time limit until alll clients needs to use the new config with the new static key. 5) After the time limit has reached, activate the VPN but now with enabled “TLS Channel Protection” in the WUI .

As an idea.

Best,

Erik

9

The OpenVPN documentation says to add “tls-auth ta.key 1” to the client config (server using “tls-auth ta.key 0”) to specify the key direction.

I noticed that IPFire does not use this (at least not for the client). It’s only “tls-auth ta.key” in the .ovpn file.

Could this lead to problems or error messages?

10

Hi Larsen,
since IPFire uses TLS-certificates the client server role is clear and there is no need to use parameter like 0 for server and 1 for client. As far as i remember 0 and 1 was used mainly for independant usage for HMAC send, HMAC receive, encrypt, and decrypt with a PSK so it was possible to use the four different parts in one PSK independantly via direction parameter. But as far as i remember IPFire never used PSKs for OpenVPN.

Best,

Erik

11

no, because ipfire uses tls-auth instead of the insecure IKEkey-auth method with username and password that most routers and router os use.

12

Ok, thanks.

I tried using my client with tls-auth settings against our IPFire without tls-auth activated today to see if this could work as described above.

Turns out it does not:
TLS Error: cannot locate HMAC in incoming packet

Seems like we will have to create a second connection on each client before activating tls-auth on the firewall.

13

Therefor i wrote above

?!

14

Yes, I know. I was hoping that the config could be patched and still be used with the server not having tls-auth activated, yet. This could have made deployment a little bit easier.

15

Good morning,
in any case you need also the static key too, only adding the directive into the conf file won´t be enough. Since you need to distribute a new file (ta.key) to the clients even if you patch the client.ovpn with the new tls-auth line, it might be may easier to generate the whole package (with activated TLS Channel Protection) via WUI and distribute it.
A possible way can look like this Block malicious OpenVPN connection attempts (fail2ban?) - #8 by ummeegge .

Best,

Erik

16

Yes, the ta.key had also been copied before testing :wink:

As there seems to be no easier way, the plan now is to distribute a new package alsongside the current vpn connection. Then at some point make a switch, and afterwards get rid of the old connection for all users.