This would tell the peer with this configuration to send all traffic for the whole 192.168.1.0/24 through the tunnel, not sure that is what OP wants. (Didn’t look at the link though)
This would tell the peer with this configuration to send all traffic for the whole 192.168.1.0/24 through the tunnel, not sure that is what OP wants. (Didn’t look at the link though)
Probably it would be much easier for you to setup tailscale. Just install it on the system you host the other services, install on the other end and use the tailscale ip. It should require minimal effort to set up with the added benefit of not having ports open, and way easier maintaining.
As for wireguard, the allowed up section tells what ips should be routed through the tunnel, it’s not that difficult, but hard to wrap your head around at first. A friend of mine also used to use the Fritzbox Implementation of wireguard and I remember you need to specifically setup what clients you want the tunnel to have access to.
Have a look at tailscale.
To follow up on this: I now use a combination of caddy as reverse proxy and authelia for authentication. In my opinion caddy is the best reverse proxy, it’s super lightweight and the caddyfiles are super easy to read. Authelia is surprisingly easy to get setup. I was a bit hesitant because it looked a little overwhelming in the beginning. When you sit down for half a day and dig into it, it’s really surprisingly straightforward.
I found that before and it’s really interesting. I didn’t really find it easy to understand, though. Maybe I’ll look into it again. As I understand it, you wouldn’t even need caddy, oauth2-proxy itself can act as reverse proxy, right?
It really does look cool. It can be deployed using Docker. I’ll have a look at it.
Well yeah, basic auth is surely the easiest method … though I rather like to go the oauth2/OIDC route.
By no means an expert, bit I’ll try: One technique would b asymmetric encryption. Every participant has two keys, a public and a private one. When I want to send you an encrypted message, I encrypt the message with your public key. This key you can make available in any way, it can’t be used in a harmful way. The message I encrypted with you public, you can decrypt using your private key, and only with that. Like this, you only need to exchange public keys used only for encryption. So no useful information for an attacker. And private keys never need to leave your hands.