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

11–20 of 80 posts

Re: WireGuard Bounce Server Setup

#11

Post by mbreese »

jjice wrote: post #2

Seems like a good tutorial. I've been using this type of set up for about 6 months now and it works well for me. I wish I had a straight forward explanation like this when I was first learning how to use WireGuard.

That was my experience setting up a WireGuard connection to my home network about 12 months ago. It was really difficult to get a straightforward explanation of how to set things up. For example, I had (as mentioned above) dynamic DNS set to update from my home router with port forwarding setup to a home Linux server (Rpi actually).

This isn't as easy as A B, but it is probably a common enough use-case. It was really hard to figure out what I needed to put in my wg.conf files. But once I got it, it was really solid.

Is there something like "WireGuard in anger" or even something like the GitHub introduction to Git for WireGuard? It seems like it would be very helpful.

Re: WireGuard Bounce Server Setup

#12

Post by ahnick »

kuroguro wrote: post #7
ahnick wrote: post #3

I must be missing something. Why go through all of this when you can just buy a domain name, setup dynamic dns on the natted network (to keep the IP updated), and then setup wireguard to route to the domain name? If you have two different networks then just use two different domains or subdomains.

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.

Re: WireGuard Bounce Server Setup

#13

Post by gruez »

This works if both sides has wireguard installed and are in the network, but is there a way to got this to work for any connections from the internet? eg. your VPS has ip 1.1.1.1, you want any traffic that goes to 1.1.1.1 to go to the wireguard interface on your PC, and any traffic set from the wireguard interface on your PC exits through 1.1.1.1. Bonus points if set it up in such so that the interface address on your PC shows up as 1.1.1.1.

Re: WireGuard Bounce Server Setup

#14

Post by mbreese »

kuroguro wrote: post #7
ahnick wrote: post #3

I must be missing something. Why go through all of this when you can just buy a domain name, setup dynamic dns on the natted network (to keep the IP updated), and then setup wireguard to route to the domain name? If you have two different networks then just use two different domains or subdomains.

Would that setup punch trough the nat tho?

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.

Re: WireGuard Bounce Server Setup

#15

Post by 1vuio0pswjnm7 »

"If you have someplace to put more secure equipment on the open net, that would be better.

A [your choice of HW] would do fine, if it runs only your code."

Idea: "Colocation centres" for users' computers instead of data centres for users' data. As directed by the author here, users would store no data on these computers.1

1. By their nature, each user-owned supernode computer would provide some discoverable metadata, as would any router, namely, the IP addresses of the members of the private network/s it supports and which of those IPs are connecting to each other, but this would be unlike the centralised repositories of millions of users' metadata we have now, managed by private tech companies.

As for the rest of this writeup, it sounds much like the need for a supernode in "LAN-over-Internet"-type P2P networks that encapsulate Ethernet-like packets in UDP packets. The supernode does not necesarily need to route traffic between nodes behind NAT (rarely necessary), it only needs to store the equivalent of an ARP table accessible by all of them.

Re: WireGuard Bounce Server Setup

#16

Post by gruez »

1vuio0pswjnm7 wrote: post #15

"If you have someplace to put more secure equipment on the open net, that would be better. A [your choice of HW] would do fine, if it runs only your code." Idea: "Colocation centres" for users' computers instead of data centres for users' data. As directed by the author here, users would store no data on these computers.1 1. By their nature, each user-owned supernode computer would provide some discoverable metadata,…

>Idea: Colocation centres for users' computers instead of data centres for users' data.

You mean this? https://en.wikipedia.org/wiki/Colocation_centre

Re: WireGuard Bounce Server Setup

#17

Post by aftbit »

gruez wrote: post #13

This works if both sides has wireguard installed and are in the network, but is there a way to got this to work for any connections from the internet? eg. your VPS has ip 1.1.1.1, you want any traffic that goes to 1.1.1.1 to go to the wireguard interface on your PC, and any traffic set from the wireguard interface on your PC exits through 1.1.1.1. Bonus points if set it up in such so that the interface address on you…

Yes this is relatively straightforward to accomplish via iptables pre&postrouting rules. I think the key insight is to realize that you're basically asking for NAT with DMZ:

Internet -> [eth0] WG BOX [wg0] -> [wg0] HOME SERVER

analogous to:

Internet -> [eth0] ROUTER [eth1] -> [eth0] HOME SERVER

Re: WireGuard Bounce Server Setup

#18

Post by ahnick »

stvsu wrote: post #10
ahnick wrote: post #3

I must be missing something. Why go through all of this when you can just buy a domain name, setup dynamic dns on the natted network (to keep the IP updated), and then setup wireguard to route to the domain name? If you have two different networks then just use two different domains or subdomains.

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?

Re: WireGuard Bounce Server Setup

#19

Post by aftbit »

yokem55 wrote: post #4

I was hoping this was some kind of stun mechanism for wireguard. No, it's just setting up a cheap wireguard server on AWS. Anyone have anything like an introduction server to help wg peers behind nat find each other?

This[1] is the best post I've seen on that _outside_ of the Tailscale writeup linked below. The clever bit is that the introduction server uses wireguard tunnels to find your endpoint information, then shares it out via DNS. Of course it still requires you to be able to run custom code on all of the endpoints, which requires supporting many different platforms.

I'm still looking for a FLOSS mesh network built on top of wireguard that can do NAT traversal between nodes and fall back to tunnelling traffic for the annoying cases where this fails. I don't really want to use Tailscale because (1) their server is not open (though this should not matter a ton for trust) and (2) they require a Google account or similar to sign up.

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

Re: WireGuard Bounce Server Setup

#20

Post by 0xbadcafebee »

1vuio0pswjnm7 wrote: post #15

"If you have someplace to put more secure equipment on the open net, that would be better. A [your choice of HW] would do fine, if it runs only your code." Idea: "Colocation centres" for users' computers instead of data centres for users' data. As directed by the author here, users would store no data on these computers.1 1. By their nature, each user-owned supernode computer would provide some discoverable metadata,…

> Idea: "Colocation centres" for users' computers instead of data centres for users' data. As directed by the author here, users would store no data on these computers.

This is basically AWS Workspaces. It can work, but it's annoying, expensive, and various latency and bandwidth issues are a killer.

Post reply on HN