How can I bypass CGNAT by using a VPS with a public IPv4 address?
I want to move away from Cloudflare tunnels, so I rented a cheap VPS from Hetzner and tried to follow this guide. Unfortunately, the WireGuard setup didn't work. I'm trying to forward all traffic from the VPS to my homeserver and vice versa. Are there any other ways to solve this issue?
You don't want to forward all traffic. You can do SNAT port forwards across the VPN, but that requires the clients in your LAN to use the VPS as their gateway (I do this for a few services that I can't run through a proxy; its clunky but works well).
Typically, you'll want to proxy requests to your services rather than forwarding traffic.
Setup Wireguard or OpenVPN on the VPS as a server VPN. Allow whatever listener port in the firewall (I use ufw on Debian, but you can use iptables if you want)
Install HAProxy or Nginx (or Nginx Proxy Manager) on the VPS to act as your frotnend. Those will listen on ports 80/443 and proxy requests to your backend servers. They'll also be responsible for SSL termination, and your public-facing certs will be set there.
Point your DNS records for your services to the VPS's public IPv4
On your LAN, configure your router to connect to the VPS as a VPN client and route into your LAN from the VPN subnet -or- install the VPN client (WG/OVPN) on each host
In your VPS's reverse proxy (HAProxy, etc), set the backend server address and port to the VPN address of your host
I've done this since ~2013 (before CF tunnels were even a product) and has worked great.
My original use case was to setup direct connectivity between a Raspberry PI with a 3G dongle with a server a home on satellite internet. Both ends of that were behind CG-NAT, so this was the solution I came up with.
Out of curiosity, why not a simple reverse proxy on the VPS (that only adds client real IP to headers), tunneled to a full reverse proxy on the home server (that does host routing and everything else) through a SSH tunnel?
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.
The SSH tunnel is just one command, but you may want to use autossh to restart it if it fails.
If you choose variant 2 you will need to configure a pass-through reverse proxy on the VPS that does TLS termination (uses correct certificates for each domain on 443). Look into nginx, caddy, traefik or haproxy.
For the full home proxy you will once again need a proxy but you'll additionally need to do host routing to direct each (sub)domain to the correct app. You'll probably want to use the same proxy as above to avoid learning two different proxies.
I would recommend either caddy (both) or nginx (vps) + nginx proxy manager (home) if you're a beginner.
Hi, whenever I try to enter the ports 80 and 443 at the beginning of the -R parameter, I get this error: Warning: remote port forwarding failed for listen port 80. How do I fix this?
Ah yes. Ports below 1024 are normally privileged and only superuser can use them (and the account you're using to ssh in is not and should not be root).
The biggest obstacle for me is the connection between the VPS and my homeserver. I have tried this today and I tried pinging 10.0.0.2 (the homeserver IP via WireGuard) and get this as a result:
Can you post your WG config (masking the public IPs and private key if necessary)?
With wireguard, the allowed-ips setting is basically the routing table for it.
Also, you don't want to set the endpoint address (on the VPS) for your homeserver peer since it's behind NAT. You'll only want to set that on the 'client' side. Since you're behind NAT, you'll also want to set the persistent keepalive in the client peer so the tunnel remains open.
On the surface, that looks like it should work (assuming all the keys are correct and 51820/udp is open to the world on your VPS).
Can you ping the VPS's WG IP from your homeserver and get a response? If so, try pinging back from the VPS after that.
Until you get the bidirectional traffic going, you might try pulling out the iptables rules from your wireguard script and bringing everything back up clean.
I do not get a response when pinging the VPS's WG IP from my homeserver. It might have something to do with the firewall that my VPS provider (Hetzner) is using. I've now allowed the port 51820 on UDP and TCP and it's still the same as before... This is weird.
I'm not familiar with Hetzner, but I know people use them; haven't heard any kinds of blocks for WG traffic (though I've read they do block outbound SMTP).
Maybe double-check your public and private WG keys on both ends. If the keys aren't right, it doesn't give you any kind of error; the traffic is just silently dropped if it doesn't decrypt.
In most distros, it's systemctl start wg-quick@wg0 where wg0 is the name of the config file in /etc/wireguard
If so, then maybe double/triple check any firewalls / iptables rules. My VPS providers don't have any kind of firewall in front of the VM, but I'm not sure about Hetzner.
Maybe try stopping wireguard, starting a netcat listener on 51820 UDP and seeing if you can send to it from your homelab. This will validate that the UDP port is open and your lab can make the connection.
The command you provided for the VPS returns UDP listen needs -p arg, so I just added -p right before the port number and then it worked. Running the homelab command returns no port[s] to connect to... Not good.
At least that points you to the problem: firewall somewhere.
Try a different port with your netcat test, perhaps? 51820 is the well-known WG port. Can't imagine they'd intentionally block it, but you never know.
Maybe Hetzner support can offer more guidance? Again, I'm not sure what or how they do network traffic before it gets to the VM. On all of mine, it's just a raw gateway and up to me to handle all port blocking.
If you figure that part out and are still stuck on the WG part, just shoot me a reply.