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)
WireGuard: Beyond the most basic configuration
51–60 of 115 posts
Re: WireGuard: Beyond the most basic configuration
#52> 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)
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
#53I'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.
Re: WireGuard: Beyond the most basic configuration
#54Re: WireGuard: Beyond the most basic configuration
#55Re: WireGuard: Beyond the most basic configuration
#56Earlier 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.
Re: WireGuard: Beyond the most basic configuration
#57Earlier 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.
Re: WireGuard: Beyond the most basic configuration
#58No 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.
Re: WireGuard: Beyond the most basic configuration
#59Not to hijack but last time I was setting up wireguard, I found this site to be super useful: https://www.procustodibus.com/blog/2020/10/wireguard-topolog...
Re: WireGuard: Beyond the most basic configuration
#60I'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…