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 (
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 used
firejail 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
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
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.