Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WireGuard Bounce Server Setup

gitlab.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: WireGuard Bounce Server Setup

#71

Post by ncmncm »

ahnick wrote: post #18
stvsu wrote: post #10

Earlier quoted context omitted.

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.

Re: WireGuard Bounce Server Setup

#72

Post by ncmncm »

zaarn wrote: post #69
ncmncm wrote: post #66

Earlier quoted context omitted.

Thank you. In this case, gnupg was, both for that user and for that host, wholly unconfigured -- evidently it was just roped in by some package dependency. So, trying to run something that depended on the system or user having gnupg configured correctly (or at all) was wholly wrong. Systemd killing my nohup s does not seem like doing me a favor. If I had wanted the process killed when my connection dropped, I would n…

Systemd doesn't kill nohups as long as the session exists. Hence your nohup works if you opened tmux or a graphical terminal and close it. But logging out terminates all processes belonging to that session that don't properly disassociate from the session. You can run 'loginctl enable-linger' to disable this behaviour or set 'KillUserProcesses=no' in /etc/systemd/logind.conf You can also use 'systemd-run --scope --us…

Thank you, this is all very helpful.

Re: WireGuard Bounce Server Setup

#73

Post by mbreese »

quantumofalpha wrote: post #47
mbreese wrote: post #32

Earlier quoted context omitted.

I can't see how the post you linked actually does the NAT traversal... Alice finds Bob's external IP:port using the registry. That makes sense. But doesn't Bob need to send a packet to Alice to setup the NAT traversal on his side? More accurately, Alice uses the SRV field to populate the wg peer information on her side -- but how does Bob know that he needs to update the peer information on his side? I think this is…

> I can't see how the post you linked actually does the NAT traversal... It assumes full-cone NAT - you punch a hole once by sending a packet to a third party, like a stun server which will along the way tell you your external ip:port, and then a full-cone NAT would forward packets coming to that ip:port back to you, regardless of the source.

Ahh. Thank you... that makes sense. I always thought NAT was destination/port specific. It seems like this would be a fairly large assumption to make.

Re: WireGuard Bounce Server Setup

#74

Post by pinusc »

aftbit wrote: post #41
stock_toaster wrote: post #39

A self hosted "TURN like" server seems like it would be simpler and more secure -- yet achieve similar goals, and yet still more robust vs funky NAT layers than a dynamic dns solution alone would provide.

I'd love to see a nice guide for setting this up. I've found the world of STUN/TURN/ICE incredibly confusing, probably because of the SIP/telephony background.

Someone linked a write-up above [1]. It's not simple, but I found it well-written, and doesn't assume too much networking knowledge. I guess it's still a young protocol and we have proofs of concepts but not full-fledged deployment-ready solutions yet...

1: https://www.jordanwhited.com/posts/wireguard-endpoint-discov...

Re: WireGuard Bounce Server Setup

#75

Post by ncmncm »

ncmncm wrote: post #60
quantumofalpha wrote: post #42

> To connect between NATted hosts, you need control of a host that is not Um, no? https://github.com/samyk/pwnat

Thank you for this. I will try it.

From the paper, "Autonomous NAT Traversal", Mueller/Evans/Grothoff/Kamkar, IEEE P2P 2010:

"Conclusion: ... the presented method works ... virtually never if both peers are behind NAT."

Still, "virtually never" is not "never".

Re: WireGuard Bounce Server Setup

#76

Post by ahnick »

ncmncm wrote: post #71
ahnick wrote: post #18

Earlier quoted context omitted.

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.

Re: WireGuard Bounce Server Setup

#77

Post by ncmncm »

ahnick wrote: post #76
ncmncm wrote: post #71

Earlier quoted context omitted.

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,…

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.

Re: WireGuard Bounce Server Setup

#78

Post by ahnick »

ncmncm wrote: post #77
ahnick wrote: post #76

Earlier quoted context omitted.

> 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,…

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?

Re: WireGuard Bounce Server Setup

#79

Post by ncmncm »

ahnick wrote: post #78
ncmncm wrote: post #77

Earlier quoted context omitted.

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.

Re: WireGuard Bounce Server Setup

#80

Post by aftbit »

pinusc wrote: post #74
aftbit wrote: post #41

Earlier quoted context omitted.

I'd love to see a nice guide for setting this up. I've found the world of STUN/TURN/ICE incredibly confusing, probably because of the SIP/telephony background.

Someone linked a write-up above [1]. It's not simple, but I found it well-written, and doesn't assume too much networking knowledge. I guess it's still a young protocol and we have proofs of concepts but not full-fledged deployment-ready solutions yet... 1: https://www.jordanwhited.com/posts/wireguard-endpoint-discov...

That was me :)
Post reply on HN