![](https://midwest.social/pictrs/image/00ee272c-7b85-45e7-9611-c24607c92ca5.jpeg)
![](https://lemmy.world/pictrs/image/8286e071-7449-4413-a084-1eb5242e2cf4.png)
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.
I mean, the basic config file for Caddy is 1 line, and gives you Let’s Encrypt by default. The entire config file for a reverse proxy can be as few as 3 lines:
my.servername.net { reverse_proxy 127.0.0.1:1234 }
It’s a single executable, and a single 3-line file. Caddy is an incredible piece of software.