Live data from Hacker News

WireGuard: Beyond the most basic configuration

sloonz.github.io

51–60 of 115 posts

Re: WireGuard: Beyond the most basic configuration

#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)

Re: WireGuard: Beyond the most basic configuration

#52
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 connect to 1.2.3.4:50000, and your router says "who the hell is this".

This is what UPNP and related tools attempt to solve. UPNP works by allowing your computer to say to your router "hey, I'm going to want inbound connections on port 50000, so if you get any, send them to me".

Other methods like STUN/TURN/etc use different techniques to get around the issue.

Re: WireGuard: Beyond the most basic configuration

#53
post #45
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.

Or the reverse, most people have specific IPs that they'd like to route traffic through the VPN but mostly don't care about the rest. Again, you wind up creating a huge list of exact IPs and creating the routing rules is a PITA.

I don't understand. Having a specific list of IPs they want to route over Wireguard is the one that is easy today. It's the inverse (everything except these IPs) that's hard.

Re: WireGuard: Beyond the most basic configuration

#56
post #33

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.

Wha... since when does Tailscale have an AppleTV subnet node!??! Those guys are on fire and I missed this.

I use mine as my Tailscale exit node.

Re: WireGuard: Beyond the most basic configuration

#57
post #3

Earlier quoted context omitted.

Are you using an internal or external service? Curious what you or others recommend... I've done a bit of both... I used CloudFlare which works fine and then I moved over to tailscale when playing with pxe / netboot and I've not decided on what to use beyond tailscale's magic dns. Unbound looks pretty nice.

I've been very pleased with powerdns for my self hosted internal DNS services. It implements basically everything you want for even the most esoteric DNS setups, and IMO, quite sanely.

I've tried many times to setup PowerDNS and never complete it because I get bogged down in the complexity. I saw they had an ansible / terraform script for deployments. Do you just use the team's docs or something else?

Re: WireGuard: Beyond the most basic configuration

#58

No RBAC is sad, though understandable. Wireguard is so much faster than OpenVPN. We use Wireguard for S2S but unfortunately need OpenVPN for our employees and contractors due to RBAC. All posts and writeups we've found trying to shoehorn RBAC into Wireguard ultimately ends up with people saying "don't do this."

There’s a very good implementation of Wireguard with RBAC. It’s called Tailscale.

[deleted]

Re: WireGuard: Beyond the most basic configuration

#60
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 agree that would be useful. I'm fairly sure it is because all the entries in `AllowedIPs` are just written as-is to the routing table, and the routing logic in the kernel (and most/all routers?) has no facility for 'does not match'. Instead the solution would be to add a explicit route to state where the excluded CIDR should be sent to. That would would be more specific and would therefore be used for matching pack…

To me this is actually one of the attractive aspects of Wireguard compared to some other VPNs, it doesn't try to manage everything within the tool and delegates to the host's normal routing mechanisms. However it still by default conflates AllowedIPs and the routing table -- you can actually separate them (Table=off with wg-quick) and then manually add routes.
Post reply on HN