Hi, thank you so much for trying to help me, I really appreciate it!

VPS wg0.conf:

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = REDACTED

PostUp = iptables -t nat -A PREROUTING -p tcp -i eth0 '!' --dport 22 -j DNAT --to-destination 10.0.0.2; iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source SERVER_IP
PostUp = iptables -t nat -A PREROUTING -p udp -i eth0 '!' --dport 55107 -j DNAT --to-destination 10.0.0.2;

PostDown = iptables -t nat -D PREROUTING -p tcp -i eth0 '!' --dport 22 -j DNAT --to-destination 10.0.0.2; iptables -t nat -D POSTROUTING -o eth0 -j SNAT --to-source SERVER_IP
PostDown = iptables -t nat -D PREROUTING -p udp -i eth0 '!' --dport 55107 -j DNAT --to-destination 10.0.0.2;

[Peer]
PublicKey = REDACTED
AllowedIPs = 10.0.0.2/32

Homeserver wg0.conf:

[Interface]
Address = 10.0.0.2/24
PrivateKey = REDACTED
 
[Peer]
PublicKey = REDACTED
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Endpoint = SERVER_IP:51820

(REDACTED would’ve been the public / private keys, SERVER_IP would’ve been the VPS IP.)

Variant 1:

• SSH tunnel established outgoing from home server to VPS_PUBLIC_IP:22, which makes an encrypted tunnel that “forwards” traffic from VPS_PUBLIC_IP:443 to HOME_LOCALHOST:443.
• Full reverse proxy listening on HOME_LOCALHOST:443 and does everything (TLS termination, host routing, 3rd-party auth etc.)
• Instead of running home proxy on the host you can ofc run it inside a container, just need to also run the ssh tunnel from inside that container.

Pro: very secure, VPS doesn’t store any sensitive data (no TLS certificates, only a SSH public key) and the client connections pass through the VPS double-encrypted (TLS between client browser and home proxy, wrapped inside SSH).

Con: you don’t get the client’s IP. When the home apps receive the connections they appear to originate at the home end of the SSH tunnel, which is a private interface on the home server.

Variant 2 (in case you need client IPs):

• SSH tunnel established same way as variant 1 but listens on VPS_LOCALHOST:PORT.
• Simple reverse proxy on VPS_PUBLIC_IP:443. It terminates the TLS connections (decrypts them) using each domain’s certificate. Adds the client IP to the HTTP headers. Forwards the connection into VPS_LOCALHOST:PORT which sends it to the home proxy.
• Full reverse proxy at home set up same way as variant 1 except you can listen to 80 and not do any TLS termination because it’s redundant at this point – the connection has already been decrypted and will arrive wrapped inside SSH.

Pro: by decrypting the TLS connection the simple proxy can add the client’s IP to the HTTP headers, making it available to logs and apps at home.

Con: the VPS needs to store the TLS certificates for all the domains you’re serving, you need to copy fresh certificates to the VPS whenever they expire, and the unencrypted connections are available on the VPS between the exit from TLS and the entry into the SSH tunnel.

Edit: Variant 3? proxy protocol

I’ve never tried this but apparently there’s a so called proxy_protocol that can be used to attach information such as client IP to TLS connections without terminating them.

You would still need a VPS proxy and a home proxy like in variant 2, and they both need to support proxy protocol.

The frontend (VPS) proxy would forward connections in stream mode and use proxy protocol to add client info on the outside.

The backend (home) proxy would terminate TLS and do host routing etc. but also it can unpack client IP from the proxy protocol and place it in HTTP headers for apps and logs.

Pro: It’s basically the best of both variant 1 and 2. TLS connections don’t need to be terminated half-way, but you still get client IPs.

Please note that it’s up to you to weigh the pros and cons of having the client IPs or not. In some circumstances it may actually be a feature to not log client IPs, for example If you expect you might be compelled to provide logs to someone.