Hacker News new | past | comments | ask | show | jobs | submit login

Lack of Wireguard docs/tutorials is unfortunate, because I'm in the same boat. I'm using Tailscale now because I just don't know enough about linux networking to figure out why my packets aren't going where they should. I suspect it's a very simple config error, but I don't know how to debug or where to look. I like Tailscale, but I'd much rather use real wireguard and eliminate a dependency on tailscale, but I can't find guides/tutorials/etc.

If anyone knows of a Wireguard walk-through to bridge two separate LANs together, I'd love to see it




> Lack of Wireguard docs/tutorials is unfortunate

The thing about Wireguard is that it's very simple and minimal. It does just one thing, and that is - establishes a layer 3 tunnel for sending IP packets between local machine and some other peers. It doesn't do mesh, it doesn't do routing (it just knows the IPs of its direct peers and that's all it does), it doesn't do bridging - all this stuff is done by other pieces such as Linux kernel, but not Wireguard itself.

> Wireguard walk-through to bridge two separate LANs

Same or different subnets for those LANs? If they're different and non-intersecting, and if you don't need cross-LAN broadcast or multicast, the simplest option is to establish a Wireguard connection between those LAN's default gateway routers (assuming you can do this), and on each of those routers set up a route that sends opposite LAN's traffic to the opposite gateway (in case of iproute2: `ip route add my.other.lan.subnet/mask via my.other.lan.gw`, how to make this persistent depends on your distro). Then, on each gateway, allow packet forwarding between Wireguard and LAN interfaces (with e.g. iptables or nftables or whatever you use there).

If you can't run Wireguard on gateways, the overall principle holds, but you'll need to distribute routes to your respective LANs via Wireguard-running routers through DHCP or whatever you use for routing on your LANs (e.g. OSPF).

And if your LANs both have the same subnet, or if you need multicast, things get significantly trickier (plus, there's inevitable question of what should happen if two machines on different LANs have the same IP). You'll probably need to run something like L2TP or GRETAP (or something else that can encapsulate you layer 2) over Wireguard.

Or maybe just use OpenVPN in TAP mode (if you want all stuff independent of any third parties) or Tailscale (because it already works).


A few years ago I decided to get my own ASN. I have a couple of VPSes running BGP with my upstreams at geographically diverse but relatively close locations (10 to 15 ms ping.) I have Wireguard tunnels between the VPSes and also from each VPS to my home network, forming a mesh w/OSPF. Originally, I was only injecting default routes into OSPF so I'd have basic redundancy if things failed, treating one provider as a secondary, not caring much about outgoing load balancing. I recently switched to internal BGP though, and am doing some load balancing w/partial tables. Pretty cool stuff. I used BIRD for OSPF and BGP.


This is my dream setup. Awesome.


Thanks! It was fun setting it up! I was originally a network engineer working for early ISPs, before moving on to more of a software focus. I was lucky enough to register my own IPv4 block back in the 90's.


The end of your comment “or use Tailscale” sums up why I would use Tailscale here.


Of course. Picking a tool is always a matter of what one already knows. If you've already learned Tailscale and it fits all your requirements - that means you go with it, unless you have some reasons not to do it (which is rare).

And Tailscale surely has one benefit here - it's one single product, with essentially no variations, so it's (I presume, I haven't ever used Tailscale myself - never needed it) easy to write a step-by-step instructions for. Generic "GNU/Linux software router with Wireguard" is an extremely vague target that impossible to give instructions for, unless you spend a lot of time describing the problem in finer detail.


> I like Tailscale, but I'd much rather use real wireguard and eliminate a dependency on tailscale, but I can't find guides/tutorials/etc.

You could use Headscale, which is an open-source/self-hosted reimplementation of Tailscale control plane, so you can eat your cake and have it too.

Curious to know, why does distrust towards Tailscale come up so often around here? They seem extremely transparent about their strategy and incentives.


> Curious to know, why does distrust towards Tailscale come up so often around here?

I have a guess - I suspect it's because in the domain it addresses, attitudes are towards self-reliance, privacy and autonomy.

If someone uses Tailscale in some cloudy (aka all someone else's computers) setup, they probably don't bother. They already shift trust and rely on other people.

But Tailscale is infrequently used to manage own devices, which is why it clashes with self-reliance attitudes. If you run your own private hardware and networks, all or many of those in your own castle, it may bug you to introduce (or I'd rather say trust) a third party unless you're forced to. Not because it's not trustworthy, but because of the self-reliance attitude and desire to have full control over what you think of your own systems.

Sure, you're forced to trust your electricity provider (but you have an UPS) or network uplink (and even then you make security precaution), but trust in Tailscale is kind of optional (it's not irreplaceable), and not everyone feel like they want it.

Pretty much the same why a lot of people frown upon IoT stuff, even if it's from rare vendors who go extra mile to make things reliable - because of the hypothetical "but what if?" and feeling that you're losing the control here.

Just a guess, though. Others' mileage may vary.


I think that's a pretty good guess.

In my personal case, It's a mix of self-reliance and a committment to open source that makes me want to have an alternative to tailscale (although I use Tailscale for company stuff and that was my call). On top of that, for personal stuff I just have very simple networking needs, and I don't want to add yet another service (a headscale instance) I have to maintain and keep running, and in the case of headscale it's particularly important because I might lose my network if it goes down! For that reason, a tailscale-only solution that is all client and no server is attractive.

Side note: the existence of headscale is the reason why I decided to pay Tailscale for company stuff. Had the clients not been open source, and there had not been a compatible FOSS server implementation, I would have spent the time/money slinging wireguard or using some other solution. I love Tailscale for opening the clients and allowing/even supporting headscale.


I found the blog articles on https://www.procustodibus.com/blog/ super helpful and well written.

You don't have to use their service to implement what they describe, in most cases.


Create a wireguard interface on each end, add the keys to them, open up the allow list for each subnet, assign a IP from a /30 (or /31) subnet on each end, set static routes to point to other end or use a dynamic routing protocol.

There are tools to automate this like wg-quick and systemd-networkd, depending on your preference.


On my synology ds418j Tailscale was faster than WireGuard over the same interface. WireGuard used 30 to 50 percent more cpu. Was strange, but not a real problem. Just an anecdote.


Tailscale userland go WireGuard implementation is often faster and uses less CPU that the kernel one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: