I’m looking into replacing cloudflare with a VPS running a reverse proxy over a VPN, however, every solution I see so far assumes you’re running Docker, either for the external reverse proxy host or the services you’re self hosting.
The VPS is already virtualized (perhaps actually containerized given how cheap I am) so I don’t want to put Docker on top of that. The stuff I’m self hosting is running in Proxmox containers on a 15 year old laptop, so again, don’t want to make a virtual turducken.
Besides, Docker just seems like a pain to manage. I don’t think it was designed for use as a way to distribute turnkey appliances to end users. It was made for creating reproducible ephemeral development environments. Why else would you have to specify that you want a storage volume to persist across reboots? But I digress.
Anyway, I want to reverse proxy arbitrary IP traffic, not just HTTP/S Is that possible? If so, how?
My initial naive assumption is that you set up a VPN tunnel between the VPS and the various proxmox containers, with the local containers initiating the connection so port forwarding isn’t necessary. You then set up the reverse proxy on the VPS to funnel traffic through the tunnel to the correct self-hosted container based on domain name and/or port.
I feel like im missing something here. This is pretty trivial and the comments i see are over complicating the hell outta everything. All you need is your VPN tunnel working. Personally i use wireguard for this. Then you just use nginx as the reverse proxy it talks to services on the other side of the VPN.
The nginx server config looks like
server { listen 443 quic; listen [::]:443 quic; listen 443 ssl; listen [::]:443 ssl; server_name my.domain.tld; http2 on; http3 on; quic_gso on; tcp_nodelay on; error_log /var/log/nginx/jellyfin.access.log; ssl_certificate /path/to/ssl/fullchain.pem; ssl_certificate_key /path/to/ssl/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; add_header Alt-Svc ‘h3=“:$server_port”; ma=86400’; add_header x-quic ‘h3’; add_header Alt-Svc ‘h3-29=“:$server_port”’;
location / { proxy_pass http://10.159.4.12:8096/; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forward-Proto http; proxy_set_header X-Nginx-Proxy true; }}
I have no idea how to do the proper code block i guess so have a paste from my reverse proxy hosted pastebin lol https://paste.kitsuna.net/upload/snail-seal-pig
Here:
server { listen 443 quic; listen [::]:443 quic; listen 443 ssl; listen [::]:443 ssl; server_name jellyfin.kitsuna.net; http2 on; http3 on; quic_gso on; tcp_nodelay on; # You can increase the limit if your need to. error_log /var/log/nginx/jellyfin.access.log; # ssl on; # ssl_certificate /etc/nginx/certificate.crt; # ssl_certificate_key /etc/nginx/certificate.key; # ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # don’t use SSLv3 ref: POODLE ssl_certificate /etc/letsencrypt/live/kitsuna.net/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/kitsuna.net/privkey.pem; # ssl_certificate_key /etc/letsencrypt/live/kitsuna.net/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; add_header Alt-Svc 'h3=":$server_port"; ma=86400'; add_header x-quic 'h3'; add_header Alt-Svc 'h3-29=":$server_port"'; location / { proxy_pass http://10.159.4.12:8096/; # proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forward-Proto http; proxy_set_header X-Nginx-Proxy true; } }
I’ve recently switched to pangolin, which works like cloudflared tunnels, and it’s been pretty good.
They offer docker support but they also support installing manually. You install pangolin on your vps via a setup script, and you install newt on a machine inside your homelab. It supports raw udp/tcp in addition to http.I’d challenge what you said about docker, though. There is very little overhead in making a docker turduckin.
And actually docker is exactly for delivering turnkey applications, not for reproducable dev environment; I imagine that they don’t have a default data persistence because not everything needs it and that’s less secure by default. LXC (which is what you’ll mostly use in proxmox) and VMs seem more for reproducable dev environments, afaict. And there are some really good tools for managing the deployment of docker artifacts, compared to doing it yourself or using LXCs: for example dockge or portainer. I gave proxmox a try, but switched to portainer recently, because managing containers was easier and they still let you define persistent shared volumes like proxmox does.Proxmox is still good if you need to run VMs, but if all you need is OCI/docker containers, then there are simpler alternatives, in my limited experience.
I have nothing useful to add, I just really love the phrase “Virtual Turducken”
If you see a Docker solution that looks nice just look at how it’s built and replicate whatever software is packaged in its
Dockerfile.apt/yum/dnf install nginx, listen on public IP of VPS, use proxy_pass to forward to your internal IP
server { listen [::]:443 ssl; http2 on; server_name service.example.com; root /var/data/websites/holding; index index.php index.html index.htm; #SSL setting ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; add_header X-Clacks-Overhead "GNU Terry Pratchett"; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; # access_log /var/log/nginx/service-access.log main; access_log off; location / { proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Proto "https"; proxy_set_header X-SECURE-REQUEST "true"; proxy_set_header Host $http_host; proxy_pass http://192.168.1.2/; #IP of the service over the VPN } }You can install nginx onto a bare metal server and run it that way.
Check the nginx docs for the specific distribution family you are usingYou mean nginx the regular web server, not nginx proxy manager, correct?
Those are not the same thing?
#til
yes the web server
this, nginx config is simple once you know how
I’ve tried too many nginx managers. I still manage all my nginx by hand. It really is simple.
You can easily forward arbitrary IP traffic if you get an additional IP for that VPS. Then you add the IP as your own on the local end, and set up routing like
ip r a 1.2.3.4 via 10.10.10.10 dev wg0where 1.2.3.4 is the extra ip, and 10.10.10.10 is your local wireguard address.With just one IP, you can forward ports over wireguard with iptables, but I failed to do that correctly.
Now I’m using xinetd to forward traffic from external ports to Wireguard with a single IP. iptables would be better but I ran out of patience.
a virtual turducken
LOL
Docker is fine for turnkey applications. Mounting external storage that persists across containers is a feature that enables that pattern.
Running Docker in a VM is also fine and has potential advantages. However I agree that it’s probably overly complex for many people.
I’m confused what you’re trying to accomplish here. Are you trying to make it look like the traffic is coming from your VPS for some reason? Nginx (amongst others) can reverse proxy tcp traffic.
You are correct, I want the VPs’s IP to be what people see, not my home IP.
There are many ways to do this and you got the right gist, but my recommendation:
- Set up a WireGuard tunnel connecting your VPS and homeserver
- Set up a layer-4 TCP reverse proxy (Nginx’s stream module/Traefik TCP routers/Caddy-L4/HAProxy are all doable) on the VPS
- Use that reverse proxy to route all TCP traffic back to the homeserver’s HTTPS service(s), via the wg tunnel
Here’s a guide that helped me with such a setup: https://theorangeone.net/posts/wireguard-haproxy-gateway/
Wireguard only need one peer to open a silent UDP port, so use the VPS’ IP and no need to portforward your homeserver. There are other more convenient solutions like Tailscale or Pangolin, but being Wireguard-based they all follow the same principle. Lastly this keeps your certs locally for TLS all the way through
Nginx, Traefik, Caddy, HAProxy…lots of options.
Nginx and Traefik are probably the most complex if you’re not familiar with either.
HAProxy is dead simple if you solely intend to just use it as a reverse proxy.
Caddy is fairly simple as well, but slightly more complex than HAP.
If you’re not familiar with routing and VPNs in general, you may want to have a look at Tailscale or ZeroTier which use Wireguard under the hood, but making the routing dead simple, especially if you’re behind a NAT and don’t want to have to mess with ports forwarding.







