Vanilla Minecraft already has built-in authentication, and the advantages listed here seem to assume that you'd leave it wide open otherwise. What advantages are there to using this instead of it?
With Vanilla Minecraft, you have have a port open to the entire planet and have to trust that the built-in security will work. The more ports you want to open to friends, the more services you are relying on to have working security.
With Tailscale, you just need to trust that Tailscale works, which seems like a much better bet given WireGuard's simple-and-auditable code plus the quality of Tailscale's dev team working on top of that.
You can technically add a whitelist of usernames for your server, but (and maybe they've fixed this since) about 6 years ago my friends and I had our server ruined by a hacker who joined and converted our whole base to lava. When we asked how he joined despite the whitelist he said it was incredibly easy to circumvent.
After chatting a bit more he eventually felt bad and placed about a hundred chests filled with diamond armor and weapons before leaving, but that doesn't really remove the sting of having your personalized base destroyed and killed the challenge for the game.
We haven't played again since this year. At least now I know how to set up a cronjob to back up our world daily :P
If you guys aren't modding and don't need the world to be running when no one is online then you might consider going with Minecraft Realms. It's like 10 bucks a month.
I'm hosting it on a VPS I use for other things, so it's sort of "free" in this case. And we haven't had more than 10 concurrent players yet, but there's about 15 of us so it will probably happen one weekend eventually. I don't really mind administering it, but Realms is definitely a good choice for a lot of people.
As someone who stumbled into the world of Minecraft as something to do with a child and their friends, I was surprised at how it all works. I might be doing it wrong but I found it pretty hard to get a server up, set up VPNs (including for remote players), modding, moderating etc.
I’m sure a lot of parents would appreciate it being easier, with an in-app purchase of VPN, or similar access to safe, self hosted game play.
However do I get a bit of a buzz seeing my child open console and get the process ID then go to terminal and kill the flakey Minecraft app when it crashes. Requested for server reboots and grumbles at server RAM allocation etc. Maybe it being hard is actually a win.
Self-hosted is supported but for this use case it seems clear Realms are what they encourage parents to go for (and in fairness, a better option for most than managing self-hosting )
During that first server we were using a 3rd party minecraft hosting provider, so no way of knowing if that was the case. I'll double check my current server though, thanks.
Edit dug it out of my old emails, it was actually actually much longer than 6 years ago! The host was Phoenixerve, seems they don't exist anymore.
I'm relatively confident that a whitelist bypass like that has been impossible since Minecraft 1.3. (2013 ish). The login handshake for an online-mode (authentication enabled) server involves a three way communication between the client, the server, and Mojang's auth server, which basically involves the client telling the server "hey, I'd like to join", then the server acknowledging, the client telling Mojang "hey, I'm attempting to connect to this particular server" here are my login credentials", then telling the server "hey, I go ask Mojang, I'm trying to connect", and then the server checking with Mojang that this given user is trying to connect to this particular server, then establishing an encrypted connection to the client.
Minecraft authentication requires a Microsoft account. People may not want to have one for ideological reasons, or not want to attach a game to the account they use for other purposes.
Also, not encouraging it, but disabling authentication allows players with pirated copies of MC to play on the server
No consumer-oriented software should require a VPN for authentication --
Wait, it's actually a good idea. Please put everything from Meta/Facebook behind a mandatory VPN so that I have zero chance of accidentally stumbling upon it.
But you need a Microsoft account to launch the game even if you're not connecting to a server that uses it for authentication. (Unless, as you mentioned, you're playing a pirate copy of the game.)
Oh, they still let you use just a Mojang account? In any case, though, there's never an extra account required to use built-in server authentication that isn't also required to launch the game, unless you pirated it.
Uhm I need this when I’m on holiday and want to do some Minecraft with my son in worlds that run on my server at home… Although vanilla WireGuard works well for that already.
And, for example, a company might be interested in a slightly earlier post about using this "ambient authentication" setup for access to Grafana: https://tailscale.com/blog/grafana-auth/
It doesn't, but getting regular folks to use it at home is how they become known enough to get recommended for businesses. They have a post specifically about this: https://tailscale.com/blog/free-plan/ "Rather, increased word-of-mouth from free plans sells the more valuable corporate plans"
And it 100% works. We're in the middle of rolling out Tailscale at our company because I and other people here had tried it personally for non-business use cases. FWIW this is also the path we took for the Outlook iOS/Android apps in the early days (and pre-Microsoft acquisition). Let people learn to love it, and then they'll want to bring it to their jobs.
IIRC, 10+ years ago my friends used to run a cracked desktop virtual network client called [hamachi], to play multiplayer local lan matches over the internet and bypass the internet lobby systems.
It looks like the authentication rests upon looking up the owner of the incoming packet's (tailnet) IP address[0].
Does anyone know whether they have measures in place to protect against IP spoofing?
Background: The OP reminded me of innernet (a Tailscale alternative) which was presented here on HN last year[1] and which is – at least in principle – vulnerable to IP spoofing[2] because it assumes incoming IP packets (with a WireGuard IP address as "source") must originate from WireGuard's wg0 network interface and cannot e.g. originate from eth0 – which, unfortunately, is not the case on most systems.
As far as I can tell from briefly looking at tsnet[3] (which is what their authentication proxy[4] uses under the hood), tsnet runs WireGuard in user space(?), so this should prevent IP spoofing. Can anyone confirm this?
It should be spoof resistance by virtue of the fact that every node on a Tailscale network sets up public key authenticated wireguard tunnel directly to any peer it’s trying to contact.
The Tailscale client its self will automatically drop any packets that arrive over the tunnel with an unexpected IP address or protocol number (TCP, UDP, ICMP only).
> It should be spoof resistance by virtue of the fact that every node on a Tailscale network sets up public key authenticated wireguard tunnel directly to any peer it’s trying to contact.
innernet does exactly that but that doesn't help with spoofed packets arriving through some other network interface, as long as you don't explicitly tell your server (in this case Minecraft) to listen exclusively on wg0.
You asked about Tailscales ability to detect and prevent spoofing. Tailscale can because, like I said, it sets up direct P2P authenticated WireGuard tunnels.
Tailscale runs wireguard in the userspace and their clients consume packets directly out of the WireGuard tunnels before passing them onto a single Tailscale virtual interface. At no point is the Tailscale wireguard tunnel attached directly to a virtual interface, the Tailscale client inspects every packet moving in either direction first. I would strongly recommend reading up on how Tailscale handle ACLs, I think you’ll find it enlightening.
I can’t make any comments about Minecraft’s ability to detect spoofed packets, like you say that depended on the servers setup. But at point it’s no longer a Tailscale problem, Tailscale can only protect you from stuff sent over Tailscale. You want protection from the internet, you need to look else where.
Only cryptographically valid packets are accepted, and then we only return peer identity information for flows from said authenticated & authorized packets.
For services you run where you do ip <-> identity authentication you have to make sure that you're only listening on the tailscale interface right? ie, if your server is listen on 0.0.0.0 then you may be open to IP spoofing?
IIUC the way the server (Graphana/Minecraft) and the proxy described in the OP interact is the following: All incoming packets pass through the proxy which is running WireGuard in user space and which then passes them on to the server (which only listens on 127.0.0.1):
> By setting the whitelist setting to 127.0.0.1, you only allow connections from the Grafana authentication proxy to be able to bypass Grafana’s normal authentication mechanisms.
Since the proxy runs WireGuard in user space it will take care of assigning the IP addresses itself (after successful authentication), meaning no IP address spoofing or network interface "confusion" is possible.
Not necessarily. On linux for example, you'll find netfilter firewall rules installed by tailscale that implement strict reverse path filtering, which will ensure that tailscale IPs can only reach your userspace process if they originated from the tailscale network interface.
(you might ask why we don't use the rp_filter sysctl for this; unfortunately linux has a broken precedence order where loose filtering overrides strict filtering, so even if we ask for strict behavior for tailscale0, if the systemwide default is loose, we get the insufficient loose behavior - so we implement RPF by hand in netfilter instead, sigh)
Just wanted to point out that there's a pretty interesting project called Geyser[0] (along with a plugin called Floodgate[1]) that allows Java and Bedrock Minecraft users to connect to the same Java server. This might be an avenue the author could take to allow the tailscale auth here to work. In my implementation I'm using PaperMC[2] as well.
45 comments
[ 2.9 ms ] story [ 111 ms ] threadWith Tailscale, you just need to trust that Tailscale works, which seems like a much better bet given WireGuard's simple-and-auditable code plus the quality of Tailscale's dev team working on top of that.
After chatting a bit more he eventually felt bad and placed about a hundred chests filled with diamond armor and weapons before leaving, but that doesn't really remove the sting of having your personalized base destroyed and killed the challenge for the game.
We haven't played again since this year. At least now I know how to set up a cronjob to back up our world daily :P
I’m sure a lot of parents would appreciate it being easier, with an in-app purchase of VPN, or similar access to safe, self hosted game play.
However do I get a bit of a buzz seeing my child open console and get the process ID then go to terminal and kill the flakey Minecraft app when it crashes. Requested for server reboots and grumbles at server RAM allocation etc. Maybe it being hard is actually a win.
Edit dug it out of my old emails, it was actually actually much longer than 6 years ago! The host was Phoenixerve, seems they don't exist anymore.
Edit dug it out of my old emails. The host was Phoenixerve, seems they don't exist anymore.
Also, not encouraging it, but disabling authentication allows players with pirated copies of MC to play on the server
Wait, it's actually a good idea. Please put everything from Meta/Facebook behind a mandatory VPN so that I have zero chance of accidentally stumbling upon it.
And it 100% works. We're in the middle of rolling out Tailscale at our company because I and other people here had tried it personally for non-business use cases. FWIW this is also the path we took for the Outlook iOS/Android apps in the early days (and pre-Microsoft acquisition). Let people learn to love it, and then they'll want to bring it to their jobs.
Does anyone know whether they have measures in place to protect against IP spoofing?
Background: The OP reminded me of innernet (a Tailscale alternative) which was presented here on HN last year[1] and which is – at least in principle – vulnerable to IP spoofing[2] because it assumes incoming IP packets (with a WireGuard IP address as "source") must originate from WireGuard's wg0 network interface and cannot e.g. originate from eth0 – which, unfortunately, is not the case on most systems.
As far as I can tell from briefly looking at tsnet[3] (which is what their authentication proxy[4] uses under the hood), tsnet runs WireGuard in user space(?), so this should prevent IP spoofing. Can anyone confirm this?
[0] https://tailscale.com/blog/grafana-auth/
[1] https://news.ycombinator.com/item?id=26628285
[2] https://github.com/tonarino/innernet/issues/26
[3] https://github.com/tailscale/tailscale/blob/main/tsnet/
[4] https://github.com/tailscale/tailscale/tree/main/cmd/proxy-t...
The Tailscale client its self will automatically drop any packets that arrive over the tunnel with an unexpected IP address or protocol number (TCP, UDP, ICMP only).
innernet does exactly that but that doesn't help with spoofed packets arriving through some other network interface, as long as you don't explicitly tell your server (in this case Minecraft) to listen exclusively on wg0.
Hence my question.
Tailscale runs wireguard in the userspace and their clients consume packets directly out of the WireGuard tunnels before passing them onto a single Tailscale virtual interface. At no point is the Tailscale wireguard tunnel attached directly to a virtual interface, the Tailscale client inspects every packet moving in either direction first. I would strongly recommend reading up on how Tailscale handle ACLs, I think you’ll find it enlightening.
I can’t make any comments about Minecraft’s ability to detect spoofed packets, like you say that depended on the servers setup. But at point it’s no longer a Tailscale problem, Tailscale can only protect you from stuff sent over Tailscale. You want protection from the internet, you need to look else where.
Only cryptographically valid packets are accepted, and then we only return peer identity information for flows from said authenticated & authorized packets.
> By setting the whitelist setting to 127.0.0.1, you only allow connections from the Grafana authentication proxy to be able to bypass Grafana’s normal authentication mechanisms.
Since the proxy runs WireGuard in user space it will take care of assigning the IP addresses itself (after successful authentication), meaning no IP address spoofing or network interface "confusion" is possible.
(you might ask why we don't use the rp_filter sysctl for this; unfortunately linux has a broken precedence order where loose filtering overrides strict filtering, so even if we ask for strict behavior for tailscale0, if the systemwide default is loose, we get the insufficient loose behavior - so we implement RPF by hand in netfilter instead, sigh)
[0] https://github.com/GeyserMC/Geyser
[1] https://github.com/GeyserMC/Floodgate
[2] https://papermc.io/