What if you live in a college dorm or use apartment wifi where they do not give you control of the port forwarding rules? Or what if you want to deploy devices into other peoples' networks (e.g. IoT)? What if you're sending someone a bootable USB image so you can do data recovery on their hard drive in situ without them having to ship it to you? What if you're behind a carrier-grade NAT and don't have a public IPv4 address at all? In these cases and many more, you might find a wireguard bounce host useful.

Honestly, I'd probably just use Tailscale for that, so I guess the bounce server solution occupies some middle ground where one doesn't have control over the network and either doesn't have the money for tailscale or likes owning their infra end-to-end.

For me, it's indeed about FLOSS and owning the system end-to-end. Plus, I want to be able to build things like Tailscale, and I can't very well do that just using the existing tools. :)

(Author here, AMA.)

If that does what you need, then it is a reasonable alternative. I would prefer the shorter routing you get. But if one of your NATs is corporate, a phone carrier, it might not work.

If you might want to provide other services, particularly a remote exit node or web service, the bounce node is a good start on that.

OPs method would allow for remoting into your home network without port forwarding, since home network would establish a connection to the 'bounce' node, which would facilitate communication between the 3rd WG client

True, but on the bounce server it looks like the ports are just being managed via nftables. Isn't that just a wash?

Don't see how... Nftables is set up once and then left alone. Or could as well just be left alone entirely.

For minimal setup, zerotier looks like the winner.

> Don't see how... Nftables is set up once and then left alone.

Same thing for a router configuration to accept inbound wireguard requests on a home network with dyndns. You set it up once and are done.

I see the benefit of the bounce server if you operate a network in an environment where you don't have the ability to control the router config; however, when you do have the ability to update firewall/router config, then I'd prefer just setting up a domain name and avoid the dependency on a third party server.

Dyndns does work when you have a say in at least one side of each potential connection, unless you want one of your NATted hosts to also act as a bounce server in a pinch.

But you do not seem to be getting that the use of nftables, for the open-network bounce server, is wholly optional.

ah, okay. Yes, I missed that. So the point of nftables then is just to avoid sending REJECT messages, so it makes it harder to determine what port wireguard is operating on?

Yes, it is my preference: When you drop packets, they stop costing you anything further, where rejecting them generates more work for you. And, you are providing attackers free information that you don't need to.

I am not sure the nftables configuration I have is right... It might permit using my bounce server to forward packets that then appear to come from it, if they happen to mention the right port. I would welcome advice.

After further investigation, I have discovered that dyndns would not solve my problem, because the firewall at one end is especially picky; even zerotier and tailscale admit (grudgingly) that they use bounce servers for such clients.

Would that setup punch trough the nat tho?

Yes, you setup the wireguard configuration to connect to the peer using the domain name and once connected, the network assigns a local IP for the connected peer that is valid on the natted network. I use this kind of setup to access my NAS system when I am traveling or working away from home.

You don't need to punch through a NAT when you have a bounce server. Both sides are already connected to the bounce server and all interaction between those peers is done through the bounce server. Thus, the peers don't need to communicate directly... so you don't need to do any NAT punching.

That's what makes this method simple... with the downside that you need a publicly exposed intermediary. But it is vastly simpler to setup than STUN.