Sounds like NFS is a way to go in your case. Longhorn adds for your setup unnecessary resource overhead and complexity.

I’m using step-ca. Its running on dedicated SBC. ACME certs created for each service renewing automatically daily. Honestly this setup wouldn’t be worth it if it wasn’t for daily cert rotation. I’m not using wildcard certs with own CA as it’s bad practice and defeats the purpose. There are bunch of different ACME renewal scripts/services. K8s cert manager handling kubernetes services automatically. Opensense has ACME cert plugin, nginx proxy manager is using external cert managed by script. I’m validating certs with DNS using TSIG. Step-ca have several integrations with different DNS services. I chose TSIG because it’s universal. There is pi-hole integration if you using that. Buying valid domain is not needed as long as you have internal DNS. You need to Install root Ca on every machine that will be connecting to services. If you have many VM’s configuration management is the way to go.

Luks full disk encryption and encrypted offsite backups. This protects from most common smash and grab scenario.

I had issues where system upgrades would loose encryption keys and full restore from backup was my only option. Nextcloud have issues with encryption, some features are not available if you enable it (don’t remember which ones now).

Generally speaking if someone has physical access to your system you’re screwed. There are many ways that physical access can be used to get access to your data including denying you access to your data.

Yeah I looked at tutorial. Port 81 is only for management (NPM admin gui). Then you have your traffic ports for proxy services. Those would be 80 and 443 normally. You would need to expose those ports to the Internet if you want to access NPM/proxy your service. Port 81 shouldn’t be exposed on your public interface make sure it isn’t or at least have firewall rule to allow only local network (ideally management network/vlan)

It’s not clear what’s the purpose of NPM in your case. Do you want to serve internal network or expose to Internet. If it’s the latter, you need to see what interface you exposed NPM port on (have to be your public network - VPS IP), your firewall needs to allow incoming connections on that port. Most likely you will be using port 443 and maybe 80 for redirect (checkbox in NPM always use TLS). Use IP address first to eliminate DNS issues. Once IP is valid test DNS with nslookup/dig to see if it resolves to your IP.

OpenSSL command needs to be executed from VPS to eliminate network issues and just validate certificate setup. The IP and port would depend on what port you exposed. 127.0.0.1 should work from that context. Once you see certificate you can execute openssl command from your local and use WireGuard tunnel IP to connect to service. This is for internal network.

Can you elaborate more on what is not working? What are you testing to conclude it’s not working?

From my understanding you’re running VPS server. You have tunnel setup to connect to the server. You’re trying to setup N.P.M. with let’s encrypt certs validating via DNS.

To continue troubleshooting you should eliminate all network paths and test from the VPS (ssh to the system). Once you have NPM setup you should be able to test certificate locally connecting to NPM exposed port.

Assuming you exposed port 443

openssl s_client -connect 127.0.0.1:443 -showcerts

If you can validate that NPM is serving endpoint with the correct certificate you can move on to troubleshooting your network path.