Personally what I do and what I would recommend is putting the reverse proxy on the VPS and having it reach out to the services over the VPN, rather than for security this is for performance reasons. Caddy and nginx reverse proxies can both be setup to cache static content. This helps remove the delay of reaching out over the vpn for some things and in my experience made a noticeable performance difference in services that had cachable content.

Nope! No security concerns!

But, seriously, if one machine in the Wireguard network is compromised, attacks can be launched on any other machine in that Wireguard subnet. At that point, whether you’re running Wireguard or not is irrelevant.

For your specific setup, the weak point is the VPS. Everything is good, but if someone successfully beaks into an account on your VPS with access to the Wireguard device (and almost nobody goes through the effort of constraining network devices by account, and of course there’s always root) they can launch attacks on any machine in the WG subnet.

It’s a little better if you’re running containers and they’re secure, but even then there are security considerations with containers. Still, that’s about the best you’re going to get: anything listening to any external internet port is running in a container with no resource runtime, and those ideally each only have limited access to the ports in the WG subnet that they need. Eg, something like:

In your diagram, your VPS is just a gateway. If the only way to log into the VPS is over WG; and if the reverse proxy is running in a locked-down container; then this is about a secure as you can make it and still allow public access.

Or: if the only way your VPS is at all accessible is over WG – all clients have to be connected to it via VPN – then it’s reasonably secure as long as no client is compromised. Then your remote devices become the weak points.

Which old Thinkpad handles all of that?