[ahnick]

> 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.

[ncmncm]

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.

[ahnick]

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?

[ncmncm]

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.