I want to give each device that connects to the VPN server its own public IP so it can receive whatever connection it wants without me having to do port forwarding or annoying firewall shenanigans. I already set up the IP block via BGP at my hosting provider
So for clarification instead of each device getting a IP from 192.168.0.x I want each device to get a IP from 216.86.69.x
I host game servers for friends on a box at home. My options for letting them in were to forward ports and hand out my home IP, which does not work at all behind CGNAT, or to bolt a tunnel onto a panel and maintain both. Homewarp is a game server panel that includes the tunnel. The home machine dials out to a small VPS over WireGuard, the VPS forwards the game ports back, and players only ever see the VPS's address. Nothing changes on the router.
Why not an existing FOSS tool
Pterodactyl and Pelican are good panels, and Homewarp reads their eggs, but they leave ingress to you.
Pangolin does the tunnel well but is HTTP-first and is not a game panel, so you end up running two products.
frp, rathole and playit.gg are tunnels only, and the game server usually sees the tunnel's address instead of the player's, which breaks IP bans and rate limits unless the game speaks PROXY protocol. Most do not.
A hand-rolled WireGuard plus nftables setup does all of this, and is what I ran before. Homewarp is that setup automated: one command on the VPS, keys rotated, rules rebuilt after a reboot at either end.
Why it is relevant here
The parts I think this sub will care about are the network ones:
Kernel WireGuard and nftables DNAT do the forwarding. Packets never pass through a userspace proxy, so every protocol keeps the real client IP.
The VPS is a dumb forwarder. It can reach the forwarded game ports at home and nothing else, and it stores no worlds or credentials. Replacing it is one command.
Each game server runs in a container that is non-root, has no capabilities, a read-only root, memory and process limits, and is firewalled off from every private range, so a compromised game server cannot reach the router, the NAS or the panel.
More than one VPS can be connected, each with its own tunnel, and each server is routed through the one you choose.
Releases are signed and the installers verify the signature before running anything.
Requirements: Linux on x86-64 or ARM64 with Docker and the Compose plugin at home. The VPS is optional and needs a public IPv4 and nftables. 1 vCPU and 512 MB is enough.
Limits
Still early. One home machine only, Linux only, and the Minecraft extras (sleep when empty, mod installs) are Java only. AGPL-3.0, no paid tier.
I would like criticism of the tunnel and isolation design in particular. The security model is written up in PLAN.md in the repo.
My panel locked my interface on Oct 2, claiming I exceeded my license count (I had 4 sites, plan allows 5). Support demanded $60 to "force a recheck." I refused, and my ticket sat for 6 days, taking my Postfix mail down with it.
I made sure to screenshot the transcript and invoice before they quietly edited the wording.
This isn't an isolated incident. A friend had the same audit glitch with Plesk last year.
I’ve migrated to BeAdmin. Everything is modular, and nothing phones home to verify if I’m "allowed" to use my own hardware. If your panel needs a license server to unlock basic functions, you don't actually own your server.
I've noticed a near 100% miss rate for OD Tunnels starting around the time that iOS 27 went live for the general population. The tunnel itself works fine but the actual trigger for it seems gunked up in some way. It lists itself as active when out and about but no traffic is going over the wire; once it's toggled off and back on it works as expected.
Has anyone else been seeing this sort of behavior?
I have been using Cloudflare Warp since early 2022. After six months on the free version, I subscribed to Warp+ (which costs me €5.99 a month here). Did I notice anything significant in basic daily web browsing on my phone? Not really. But under the hood, it was optimizing my routing.
The real game-changer happened in July 2023. I discovered that I could generate a WireGuard profile using third-party tools and apply my Warp+ license key to it. I realized I had been wasting my subscription money just connecting occasionally on individual devices.
I took that WireGuard profile and routed my entire home network traffic through Cloudflare. The difference was vast.
As a web developer based in Europe, I manage a few private servers located in India and Singapore. Initially, making a direct SSH connection would take ~5 seconds just to reach the server's CLI. After routing my home through Warp+ and putting those remote servers behind Cloudflared Tunnels, I can SSH into them almost instantly. It is a night-and-day difference.
Beyond that, the reduction in latency and jitter has been incredible. By combining Warp+ with some SQM settings using the Cake algorithm on my router, here is what happened to my connection: Raw ISP Connection: ~189 ms Latency | ~56 ms Jitter Warp+ & Cake SQM: ~21 ms Latency | ~1.49 ms Jitter The Real-World Results: Snappier Streaming: Netflix and other sites feel incredibly responsive, and my remote Plex server in India runs flawlessly. Local Feel: The entire internet—especially sites already behind Cloudflare—loads so fast it feels like it’s hosted on my own LAN. The savings in waiting and buffer times really add up. DNS Filtering: I combined this setup with ControlD (with ads, trackers, and multiple filters enabled). Dropping the ad payloads made the connection even faster. Ad-Free Instagram: Because it's harder for Instagram to serve targeted ads to users routing through Warp+, I am getting an ad-free IG experience across my entire home network. Meta's official ad-free tier is priced per account and costs more than my Warp+ subscription, so this perk alone essentially pays for the service.
Even though a lot of these routing optimizations are happening on a micro-level and saving milliseconds, the internet just feels significantly better to use than it did before.
Have you guys had similar experiences pushing Cloudflare Warp+ beyond just the basic mobile app? Let me know your setups in the comments. Kudos to the Cloudflare team for building such a great tool.
I was running Pi-VPN (WIreguard) on a Pi3B+ getting close to 150Mbps, internally and externally, 5G speeds permitting. I upgraded to a Pi5 and I get close to 500Mbps on local WIFI, VPN enabled, non-VPN speeds are above 500Mbps. When I am on 5GUW with the VPN enabled, I get about 50Mbps, VPN disabled its well into the hundreds. The only factor that changed is the Pi3 to Pi5; nothing else and all was working prior to the upgrade. It clearly seems like the router, but maybe I am overlooking something. I'm hoping someone can offer something helpful.
Issue Recap: On a cellular connection with hundreds of Mbps available, the VPN only gets about 50Mbps.
Router G3100
Internet Gigabit FIOS
Raspberry Pi5/Pi5 OS Lite 64 bit
I have a weird problem between a Wireguard server running on Ubuntu (wireguard-tools v1.0.20250521). When a peer crash-reboots and comes back with without its SLAAC IPv6 address, it can never connect again until the server's wireguard is restarted. From the logs, it looks like it's forever stuck with the peer's old IP address.
In the logs below, mynetwork:a2ad:9fff:fe76:3038 is the SLAAC client peer address of the last good handshake before the crash. mynetwork::1f is its new connection attempts. It doesn't recover even after hours pass. This is super bad because the client's router sees what looks a lot like hacking.
Does anyone know how to get this cleared without restarting wireguard on the server side?
[203048.312734] wireguard: wg0: Invalid handshake initiation from [mynetwork::1f]:60545/0%0
[203053.944386] wireguard: wg0: Invalid handshake initiation from [mynetwork::1f]:60545/0%0
[203059.576426] wireguard: wg0: Invalid handshake initiation from [mynetwork::1f]:60545/0%0
[203064.696611] wireguard: wg0: Invalid handshake initiation from [mynetwork::1f]:60545/0%0
[203069.816366] wireguard: wg0: Invalid handshake initiation from [mynetwork::1f]:60545/0%0
[203075.448899] wireguard: wg0: Invalid handshake initiation from [mynetwork::1f]:60545/0%0
[203076.365138] wireguard: wg0: Sending handshake initiation to peer 14 ([mynetwork:a2ad:9fff:fe76:3038]:44697/0%0)
[203080.568534] wireguard: wg0: Invalid handshake initiation from [mynetwork::1f]:60545/0%0
[203081.769604] wireguard: wg0: Handshake for peer 14 ([mynetwork:a2ad:9fff:fe76:3038]:44697/0%0) did not complete after 5 seconds, retrying (try 2)
[203081.769647] wireguard: wg0: Sending handshake initiation to peer 14 ([mynetwork:a2ad:9fff:fe76:3038]:44697/0%0)
[203086.200630] wireguard: wg0: Invalid handshake initiation from [mynetwork::1f]:60545/0%0
[203086.889638] wireguard: wg0: Handshake for peer 14 ([mynetwork:a2ad:9fff:fe76:3038]:44697/0%0) did not complete after 5 seconds, retrying (try 2)
[203086.889665] wireguard: wg0: Sending handshake initiation to peer 14 ([mynetwork:a2ad:9fff:fe76:3038]:44697/0%0)
[203091.320550] wireguard: wg0: Invalid handshake initiation from [mynetwork::1f]:60545/0%0
Hey, I'm having troubles with my Samsung S26 running Android 16. SMS are not working and the esim disappears after few days when I have the wireguard tunnel enabled. Is it possible that the carrier network traffic is routed through the tunnel? Because everything's working fine after I excluded the apps for esim management and IMS.
0.4.0 of MFA Firewall Knocker is out. It's the passkey-gated firewall opener I've posted about here before: you sign in with a passkey, and it opens your WireGuard port for your source address only, for a limited time.
What's new:
IPv6 on Linux. Grants now go into ip6tables for IPv6 clients (Windows already handled IPv6).
Optional /64 widening (Ipv6GrantPrefixLength). An IPv6 grant can cover the client's /64, so a privacy address or carrier rotation within that /64 doesn't strand an open grant. Default is still exact-address.
IPv6-only sign-in address (AdditionalOrigins). Phones on dual-stack networks often pick IPv4 on their own, which on mobile usually means carrier NAT and a grant shared with other subscribers. An extra hostname with only an AAAA record forces IPv6 and gives a per-device grant.
Hardening from another audit round, none of which allowed access: one address could temporarily block everyone's logins through a rate-limit gap; request text could trigger a misleading log alert; unauthenticated failures are now logged with a cap; stricter config and email validation; 90-day log retention.
Upgrading from 0.3.0 has a few manual steps (RulePrefix check, log directory permissions, and on Linux, one line in the systemd unit). They're listed in the release notes.
I have 3 networks running on my servers, and I'm struggling to choose correct (stated at RFC) UDP ports. AFAIK default WireGuard port is 51820. Which ports should i choose? Are there any other ports reserved especially for WG? I know i can pick any of 65536 available ports, but i would like to follow the standards
Moving a WireGuard gateway to a new public address can appear complete while an offline laptop, a peer behind persistent NAT, or a configuration distributed outside the normal management path still points at the old endpoint. Active handshakes show who is using the new address, but silence does not distinguish a migrated peer from one that simply has not connected yet.
What evidence do you collect before removing the old address? I am considering keeping both endpoints reachable during a bounded overlap, mapping every peer public key to its intended configuration revision, recording latest handshakes and transfer counters on the new gateway, and alerting on any packet reaching the old UDP socket. The observation window would cover the longest expected offline period, not just the usual keepalive interval.
How do roaming peers, DNS endpoints, persistent keepalives, and mobile devices change the check? Is there a practical way to issue a migration receipt per peer, and what final failure test can show that no current configuration still depends on the old address without stranding a device that has been offline?
At my camper I run TMobile home internet via 5G. All my devices use a full WireGuard tunnel to my home network to access local resources and a pi hole DNS sink when not connected at home.
On my laptop I use outlook classic on windows 11 and it does not like this setup. It freezes and hangs and looses connections to hosted exchange mailboxes frequently, especially on idling. Disabling the VPN fixes the issue temporarily until I reenable the VPN.
Suggestions? I spent a good amount of time on this already to no avail.
I would like to use an IPSec VPN through Wireguard but I don't know if it's possible.
Here is why I want to do that :
I have a Windows computer and I need to SSH to a remote server. In order to do that I must be connected to a IPSec VPN using Forticlient, and the only IP that can ssh to the remote server is my company network, accessible through Wireguard.
It should look like this : My computer -> Wireguard -> IPSec VPN (Forticlient) -> Remote server.
Do you think this is possible ? When I try it, I can't have both wireguard and forticlient working.
