Might want to have a look at your mobile site, it seems to cut stuff off on Firefox for Android.
Thank you for the heads up, turns out it was the custom html code in the code blocks causing the issue. Fixed now.
Yeah, seems fixed. Thank you.
Seems to be a fixed width site, indeed.
An excerpt from the Wireguard Whitepaper:
One design goal of WireGuard is to avoid storing any state prior to authentication and to not send any responses to unauthenticated packets. With no state stored for unauthenticated packets, and with no response generated, WireGuard is invisible to illegitimate peers and network scanners. Several classes of attacks are avoided by not allowing unauthenticated packets to influence any state.
After opening an SSH port and watching the number of attacks I understand the concern about opening any port on a router, but it seems the worry about opening a port for WG is way overblown.
As of now I can find zero reports of a properly configured open WG port ever being successfully used by attackers to access a network.
Anyone have better/more recent info?
At an age of ai hacking there is no way I am opening ports on my router. Especially now at the beginning when we don't know how much is already being exploited.
None of this is especially complicated
It is for an absolute noob like me... i need vacation so i can start learning all this networking jargon.
Thank you for sharing though!
Just to clarify for my simple brain - vps1 has just 80/443 open, vps2 just has a wireguard port open (51825 or whichever). Vps2 has no domain pointing to it's public IP, vps has your domain pointing to it. Vps1 and home server have wireguard configs pointing to the vps2 public IP, so punch through automatically. Is that all correct?
I think I have the same setup but with vps1 + 2 combined but that means it's public IP is easily found by the domain (one includes a public business website) and has WG ports open (although my understanding is this in itself is not an issue as WG gives no reply)
Have you opened an SSH port on both vps1 and vps2 for backup or happy to rely on wireguard? Thinking about it, you could open up the port on the vps but use the providers firewall to block the port - if needed can login to their site, open the port and then SSH in - would this work? They have KVMs for emergencies but just trying to think of worst case scenarios.
Exactly that, VPS2 handles the WireGuard port and has no domain pointing to it, so it’s basically hiding in plain sight. VPS1 holds the domain and handles the web traffic.
I keep SSH open on both, but locked down (key-based auth + restricted to my IPs).
Your idea of using the provider firewall (Ionos in my case) as a “mechanical” lock is a good one, block it at the edge and only open it when needed. I’ve thought about doing that, but I’m generally happy relying on a hardened SSH config and the provider’s KVM if everything goes sideways.
Awesome idea then, I'll have to kook into it.
What did you not like about Headscale? I started using it recently and it seems fine so far. Works identically to Tailscale.
It's not that I didn't like it, I just wanted to back to basics! A simple config file on each machine, job done
https://github.com/wg-easy/wg-easy
Needs like 100MB RAM to run, so it can basically run on almost anything. If you like some extra security: Do another layer of authentication in the reverse proxy that faces the internet.
I'm rusty since it's been awhile, but I don't understand why you need two VPSs. I have a similar setup just using one. It was mainly to get around the ISP NAT. My DNS points to the VPS, and it forwards traffic to/from my home server over the WG connection with IPtables rules.
You're right, and for a lot of people, one VPS is the sensible choice. I actually addressed this in the post:
"VPS1 is my web-facing server. It handles the public side of things. VPS2 is the VPN hub. At first glance, that probably looks unnecessary. Strictly speaking, it is unnecessary. I could have crammed WireGuard onto VPS1 and called it done. But splitting the roles makes the whole thing cleaner.
One machine serves public traffic. The other handles VPN duties. That means fewer networking compromises, fewer chances of Docker or firewall rules becoming annoying, and a clearer separation between the public-facing stack and the private tunnel. It also means I can change one side without poking the other with a stick and hoping nothing catches fire."
Gotcha, didn't realize it was a blog post haha. As far as my personal experience, I never have to touch it. Once I did a dist-upgrade and broke it, but fixed it with a backup.
Netbird could be a nice alternative.
I am a neophyte in homelabbing. What is Netbird doing exactly?
I read the github page and didn't really understand what is the use case for that.
This is an interesting article, but the crux of the setup isn't described : what is the configuration on your home server?
Creating a wireguard tunnel is pretty simple, but managing how everything is handled behind the VPN is more challenging.
The home server is an old, low-powered mini PC running Debian. It acts as the bridge between the WireGuard tunnel and my local LAN.
I've just finished migrating one of my AdGuard Home instances onto it today. Its role is now twofold:
Routing: It has ip_forward enabled and a bit of NAT (iptables/nftables) so that traffic arriving from the VPN can actually "hop" onto the local network to reach my other VMs and containers.
DNS: It provides ad-blocking for the tunnel. VPN clients point to this node's internal WireGuard IP for DNS queries.
Technically, it's just another WireGuard peer, but with AllowedIPs configured to advertise my 192.168.x.x subnet back to the hub (VPS2). This is what allows VPS1 and my mobile devices to resolve and reach home services without a single open port on my router.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| DNS | Domain Name Service/System |
| IP | Internet Protocol |
| ISP | Internet Service Provider |
| NAT | Network Address Translation |
| SSH | Secure Shell for remote terminal access |
| TCP | Transmission Control Protocol, most often over IP |
| VPN | Virtual Private Network |
| VPS | Virtual Private Server (opposed to shared hosting) |
8 acronyms in this thread; the most compressed thread commented on today has 12 acronyms.
[Thread #286 for this comm, first seen 12th May 2026, 13:20] [FAQ] [Full list] [Contact] [Source code]
The article makes sense. I think it's good to note that if the services you're running makes outbound requests (e.g. a Matrix homeserver), you could also tunnel outbound traffic to the same VPS as your inbound, so your residential IPs won't be leaked.
I've written about a similar setup, but for Tailscale nodes, here.
I thought about setting tail scale up for my home server but then I realized I've got no one I want to open myself up to and just use the VPN to connect to my stuff. Good setup, I like 💖
It's not clear to my why you absolutely don't wan't to expose your home port.
From a security standpoint, you are still exposing your services to the public anyway (only the TCP stack is not, which is likely the smallest attack surface).
If you had a simpler reverse-proxy VPS, it would still hide your home server IP from clients. Your ISP would still only see encrypted traffic (https). Since you use adguard already, you can target dns-over-https upstreams to hide all DNS traffic too (eventually have a firewall rule to block outgoing dns queries if you don't trust your application).
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!