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

WireGuard: Beyond the most basic configuration

sloonz.github.io

Post reply on HN
Print view View original

101–110 of 115 posts

Re: WireGuard: Beyond the most basic configuration

#101

Post by criddell »

AnonC wrote: post #98
criddell wrote: post #18

Earlier quoted context omitted.

Is that true? I’m not 100% sure, but I think I’ve printed while I was away from home and I only have Tailscale software installed on my AppleTV.

I'm intrigued. Could you please elaborate on your setup, what Apple TV provides in this mix and how it is used? Is the Apple TV always powered on (24x7)?

There isn't much to say. The AppleTV is like any other computer. I installed Tailscale, set it as an exit node and turned on subnet routing.

The AppleTV is always powered on, but it only uses 0.3 watts while idle.

Re: WireGuard: Beyond the most basic configuration

#104

Post by feurio »

rudasn wrote: post #25
tomjen3 wrote: post #9

I had hoped that this included a way to configure wireguard to get clients from some other place: It would be really nifty if you could configure it to read from LDAP or similar.

Yeah, that's the biggest pain point I think. Syncing configs once changes are made (new peers, new access rules, pre shared key rotation etc). It's one of the reasons I'm working on wirehub[0], as a way to distribute configs to both end users (share a link) and machines (have a script to periodically pull from wirehub). Not the perfect solution, but one that does not require additional clients/agents/software to be i…

I've built a proof-of-concept WireGuard VPN for work (SSO with mTLD portal/OIDC, BGP/WG tunnels to link edge servers into the network) and the team love it - better than the Cisco VPN they'd have to use otherwise.

Only problem is the config - I'd love a simple alternate WG app (for macOS/Windows) that could pull a config from a remote endpoint (checking signing) and bring up a WG tunnel with the config presented.

I've written a Golang client which shows up in the macOS menu bar and handles all this, but it's using the Brew WireGuard command line tools and needs sudo, etc., etc., so it's not really suitable for the average user.

Re: WireGuard: Beyond the most basic configuration

#105

Post by n4bz0r »

akerl_ wrote: post #52
n4bz0r wrote: post #51

> Some applications (looking at you, BitTorrent client) do not play well behind a NAT. I've seen a number of such warnings, but never personally encountered the issue. Is that because I've been always sitting behind a router? Or that's just an ISP thing that I got lucky with? Like, my IP isn't "grey" enough? (always had dynamic IP)

The reason that peer-to-peer tools tend not to work well behind NAT is because peers can't initiate inbound connections to you. So your router gets 1.2.3.4 as an external IP. And it assigns you 192.168.1.10 as an internal IP, and handles NAT for your outbound connections. You start your torrent client and it advertises "hey, I have all these Linux ISOs, and I'm at 1.2.3.4:50000, come connect to me". Peers try to conn…

This makes perfect sense on paper, but I disabled UPNP in router settings at some point just to see what happens and the torrents still work to this day. No issues with no apps whatsoever. That got me confused and I assumed that NAT masquerading is responsible for such "port forwarding" (having the address translation table and all that).

I'm currently using Mikrotik router with the latest RouterOS and Transmission/qBitTorrent for the clients if that helps. Any idea why is this the case?

And if (just in case) Mikrotik's implementation of NAT does in fact do "UPNP", why add separate UPNP settings? By the looks of things, I would assume that, when disabled, UPNP still works, but with some default rule set, and when enabled, you get to fine tune the interfaces. But that's just a wild guess. No mentions of such behaviour in the official wiki.

Sorry, Mikrotik does some arcane things so learning network concepts on RouterOS often leaves one with more answers than questions :')

Re: WireGuard: Beyond the most basic configuration

#106

Post by caconym_ »

zaptheimpaler wrote: post #86

Im trying to set up a personal server with services that may be accessible from the web with a real domain name or only via Tailscale. I got the web part working with Caddy and mapping subdomains to services, but the problem is Tailscale Magic DNS doesn't support subdomains. I could try to host services on paths like "blah.blah.ts.net/svc1" and strip the paths in Caddy but that causes all sorts of problems that you h…

> is this a limitation of Wireguard?

Wireguard and Tailscale aren't the same thing, and "Tailscale Magic DNS" has absolutely nothing to do with Wireguard.

This is a great example of why "just use Tailscale" is bad advice. It has some great features, but if you don't need those features then you're needlessly locking yourself into a tightly integrated networking stack which is going to get in your way anytime you want to stray from the beaten path.

If your application really is personal, my advice is to ditch Tailscale and just use Wireguard. Any halfway decent router software, like OpenWRT or pfSense, will be able to run Wireguard as a virtual network interface and a local DNS server allowing you to set up static records, delegation, etc. however you want. You'll have to deal with certificates yourself, but that will be true anyway if you try to get some local DNS thing to play nicely with Tailscale.

Re: WireGuard: Beyond the most basic configuration

#107

Post by bogantech »

tptacek wrote: post #84
bogantech wrote: post #81

Earlier quoted context omitted.

> The point of the WireGuard design is to be agnostic to "upper-layer" concerns like this; And there will probably never be any standard (non-commercial) "upper-layer" because of this. The project prides itself on being much simpler than IPSEC etc but that's easy when you leave out half of the functionality

That's a good thing. The higher up the stack you go, the less value there is in standardizing, and more painful the costs (of being constrained in implementation). Also: it is much simpler than IPSEC. Pretty much everybody can get WireGuard working in minutes. It's approximately as easy as setting up SSH. That's simply not true of IPSEC. Anyways, I think the jury is in on this one.

> Pretty much everybody can get WireGuard working in minutes.

You can get anything working in minutes, even IPSEC if you are using static keys with no authentication or authorization involved

Re: WireGuard: Beyond the most basic configuration

#108

Post by tptacek »

bogantech wrote: post #107
tptacek wrote: post #84

Earlier quoted context omitted.

That's a good thing. The higher up the stack you go, the less value there is in standardizing, and more painful the costs (of being constrained in implementation). Also: it is much simpler than IPSEC. Pretty much everybody can get WireGuard working in minutes. It's approximately as easy as setting up SSH. That's simply not true of IPSEC. Anyways, I think the jury is in on this one.

> Pretty much everybody can get WireGuard working in minutes. You can get anything working in minutes, even IPSEC if you are using static keys with no authentication or authorization involved

If you've done it a bunch before. People coming to WireGuard cold can get it set up in minutes. That's why it won: because it's much, much simpler.

Re: WireGuard: Beyond the most basic configuration

#109

Post by ghthor »

sevg wrote: post #6

I've always been slightly puzzled about why there isn't an easy built-in way to tunnel all traffic (ie, AllowedIPs = 0.0.0.0/0, ::/0) EXCEPT for some specific IPs. You end up having to programmatically generate a massive list of CIDRs that include everything except those specific IPs.

I wonder if you can add a peer to your config and set these excluded ips there, then never connect it.

Re: WireGuard: Beyond the most basic configuration

#110

Post by arantius »

n4bz0r wrote: post #105
akerl_ wrote: post #52

Earlier quoted context omitted.

The reason that peer-to-peer tools tend not to work well behind NAT is because peers can't initiate inbound connections to you. So your router gets 1.2.3.4 as an external IP. And it assigns you 192.168.1.10 as an internal IP, and handles NAT for your outbound connections. You start your torrent client and it advertises "hey, I have all these Linux ISOs, and I'm at 1.2.3.4:50000, come connect to me". Peers try to conn…

This makes perfect sense on paper, but I disabled UPNP in router settings at some point just to see what happens and the torrents still work to this day. No issues with no apps whatsoever. That got me confused and I assumed that NAT masquerading is responsible for such "port forwarding" (having the address translation table and all that). I'm currently using Mikrotik router with the latest RouterOS and Transmission/q…

Because this misunderstanding and limitation is so common, BitTorrent has workarounds in place.

See https://superuser.com/a/1548724

Post reply on HN