OpenVPN: How safe is a 24-7 open port static key setup? With proper encryption used. (AES256)

Question

In a normal setup (cert), you have a strong encryption - just like here - for example, AES256. But you also use dh and the tls params. Just to be absolutely secure.

Now, if you use the static key setup (read), which is a simple 2048-bit key file shared between the server and client that you transfer yourself through a previously established secure channel... then you are not able to use dh and tls.

How safe is to have the server running 24-7 on a custom port, using this static key setup?
Copied from the sample server.conf file:

# For extra security beyond that provided
# by SSL/TLS, create an "HMAC firewall"
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
#   openvpn --genkey --secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be '0'
# on the server and '1' on the clients.
;tls-auth ta.key 0 # This file is secret  

dh provides forward secrecy.
This is what you will miss without the normal certificate based setup.
By the way:

• Let's imply the server is DDoS protected to an extent. OVH and both Hetzner, and even VPS providers now offer DDoS protection so it's pretty much a standard.
• Let's imply the user has a firewall, and only SSH and OpenVPN is allowed.

Update #1:
Let me summarize things.

• Static Key is just one file that you copy to your server, and to your OpenVPN folder.
  It will allow you to have a very simple setup with proper encryption even. (AES, and so on).
• This setup, however, lacks forward secrecy. This is stated on the official OpenVPN website.
• Not only that, it will also disallow you to use the "HMAC firewall".
• Losing forward secrecy is a clear drawback(*). That is half of the answer.
• But what about the HMAC Firewall? Does it make your server vulnerable?
  Your OpenVPN easier to get breached?

(*) - Of course for someone to decipher the data, that specific someone needs to log every bit of data. Then, he has to acquire your secret key. Then, he has to somehow - spending insane amount of manhour and effort - rebuild all of the data into meaningful data. This is still a serious concern if the data submitted through OpenVPN is sensitive.

Answer 1

Source: https://openvpn.net/index.php/open-source/documentation/howto.html#security

"Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key."

Answer 2

Security can be tough, lots to keep up with and little time to catch up once comprised if you don't already have a plan for when your service gets compromised.

Running any public facing server 24/7 is a huge risk to your services and for a VPN risks your clients privacy and security too because what was once a trusted forwarder of network traffic can swiftly turn into a MiTM box. This risk would only increase if forward secrecy features where disabled as already answered by @Z.T. and the likely hood that your system goes goes rough without notice only increases if other features that enhance security are also turned off.

I've had many of my services attacked and from these experiences I'd suggest using some forms of service separation on the host (vmware, firejail, anything more restricted than plain chroot jail) file system that you're comfy with using and if possible having two VPN servers in virtual containers or sandboxes that swap on and off using cron schedule or other rotation method of your choice that are installed within the sandbox controller of your choice. This kind of setup allows for the service that's not on to dump logs as well as grab security updates from your package manager while the other service happily serves your clients.

The easiest setup I've rolled usedfirejail and OpenVPN as with firejail bridge networking interface magic, two separate jailed files systems with OpenVPN installed to each (used debugging software, strace at this point to build my own firejail profile to further restrict available attack surface to the chroot & host file system as well as network interfaces and niceness settings) and used some Bash scripting to make cron scheduling of switching iptables forwarding rules and rolling updates on the downed service a bit easier to manage.

This process I setup goes back and forth between server jailed file systems for a while until, for a short time, both are auto terminated for the host to grab it's security updates. Time spent keeping things going with manual assistance was reduced to once or twice a month and my clients haven't complained since being keyed and my duplicating the setup on a backup device for when the main host goes down for its updates. They've client software capable of rolling over to the next available vpn and a handful of public keys; just to make things more interesting for any that peek and cause to headaches with those that may obtain keyed access unauthorized as the failure to reconnect after switching on the service side sends alerts to the logs if clever.

This wasn't easy to setup, the automation parts, and my notes and scripts on the subject aren't ready for general consumption just yet. But I'll provide ya with two solid resources I used, a bonus tip on DNS leek prevention. That way you've more to go on than just my hot air about the above search terms as guidance.

Guides I can suggest

• the guide by Justin Ellingwood - on Digital Ocean wrote helped me get allot of the foundations figured out with keeping service file systems separate from host; though you'll want to substitute the web/php server setup in that guide for your own steps of OpenVPN setup and sort out the automation with the task scheduling daemon of your choice too if you wish to replicate what I've described.
• the OpenVPN docs - policy sections where very helpful in setting clients to very specific rolls.
• bonus points prevent DNS leak test from warning clients of your server allowing outside DNS look-up once connected.

Now one last thing, nothing, nothing, is 100% secure, not when allowed to interact with a large enough client base and certainly not when networked with with the internet. The above suggestions are only presented based on my own experience with mitigating risk to hardware and clients and significantly abbreviated to only pertain to the OpenVPN servers I've had to administrate over without going into every nitty-gritty detail of Harding ones services in general.

Specific pointers on OpenVPN questions asked

• the openvpn --genkey --secret ta.key command should be used as the manual suggested. Both server and clients will have a few certs/keys and a config for negotiations of networking permissions. It's a trick to keep track so I suggest using sub-directories that are reasonably descriptive during initial setup to keep organized.
• even with only ssh and OpenVPN ports open you'll still run great risk to your clients if your security isn't up to snuff running as you've described. While I've not seen much on OpenVPN exploits ssh and some if it's auth/fs stuff has the possibility to do harm to your server if miss-configured or not kept up to date. Consider port knocking firewall automation and fail2ban at the least to mitigate some risk.
• DDoS is only one of an ever increasing attacks that are carried out, definitely look into log monitoring software like fail2ban and patch sets like tarpit both of which will help on the firewall side of security but don't exclude file system security and integrity, one I can suggest from personal experiance with is tripwire for monitoring when, how and who modified host system files. Setting up alerts for fail2ban and tripwire can be a pain depending on local or external network choices but it's very much so worth it to have some clues to go on when cleaning up after a breach.
• finally forward security is very important as without it enabled it becomes much easier to monitor the encrypted version and then after comprise; replay of all data logged that previously wasn't readable.

Hopefully you can take some of the above and improve your clients experience.