_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Tailscale Peer Relays
mercutio2 wrote 2 hours 31 min ago:
Wow! I just spent a good chunk of time last week setting up headscale
and split horizon SSL behind my network, and I expected I was going to
just expose a Wireguard UDP port, but discovered no, itâs DERP or
nothing. DERP has been OK, but I think just exposing a UDP port on my
local network is better.
If weâre really confident in the security of that UDP client, that
is. I feel very comfortable exposing a Wireguard bastion, time will
tell how secure whatever protocol tailscale is serving, here, will be.
snapplebobapple wrote 2 hours 36 min ago:
Tailscale playing catchup to netbird...
lukashahnart wrote 2 hours 46 min ago:
I love Tailwind and use it on all my devices, but I'm not sure I really
understand what this is.
elcritch wrote 4 hours 30 min ago:
> We believe our new Tailscale Peer Relays connectivity optionâunique
to Tailscaleâgives customers the best performance and flexibility.
Seems pretty similar to some of the stuff ZeroTier was doing years ago.
Hard to claim it's unique to Tailscale. Charging for it above and
beyond the per user costs seems overboard as well.
depr wrote 8 hours 50 min ago:
You can use Tailscale to connect services together (not just someone's
laptop to a service, replacing OpenVPN), but what if Tailscale has an
outage? Will my services not be able to find each other anymore?
snailmailman wrote 8 hours 43 min ago:
The tailscale login servers had an issue last week. My local network
had an issue at the same time and all connections dropped. Then none
of my stuff could reconnect because I couldnt connect to tailscale :(
Looking into setting up my own headscale instance now. This is the
first issue Iâve had with tailscale but seems dumb that my local
lan devices couldnât even talk to each other.
apitman wrote 10 hours 4 min ago:
Main downside I see compared to DERP is there's no way for this to work
in the browser since it's native UDP. I wonder if it'd be possible to
make it work over WebTransport in the future.
raggi wrote 9 hours 4 min ago:
(Tailscalar) I'm very bullish on WebTransport in the future, but, it
doesn't solve for NAT traversal. I'm watching keenly as well how Iroh
gets on with QAD, relatedly.
If it all comes together this may well become more magic :D
apitman wrote 8 hours 10 min ago:
But this is specifically for relays, so you shouldn't need NAT
traversal right? ie in the browser you already know p2p isn't going
to work (unless Tailscale implements WebRTC support) so you just go
straight to relays for everything.
I hadn't heard about iroh using QAD. Thanks for that.
fariszr wrote 10 hours 12 min ago:
Is there a way to force clients to use a relay?
It seems like this is only meant as a fallback, but what if a relayed
connection is actually faster (like when direct peering between tailnet
members is slow, not rare in consumer connections)
einichi wrote 1 hour 19 min ago:
Just set the relay up as an exit node too
alanchen wrote 12 hours 16 min ago:
Any reason this is not supported on iOS/tvOS devices? Would love to
make it work on my Apple TV!
neodymiumphish wrote 12 hours 6 min ago:
I'm paraphrasing what one of the engineers said when I asked this
question to the team (I'm a TS insider):
There's an application size limit associated with NetworkExtension.
[1] So they would need to get the binary size smaller in order to
implement this on iOS or Apple TV.
URI [1]: https://developer.apple.com/documentation/networkextension
moontear wrote 12 hours 41 min ago:
One thing I didnât understand: it uses an UDP port of my choice. What
IP is it using? Everything via the tailnet or do I need to open this
port to the internet?
If only available via Tailscale/tailnet - how is connectivity better
since if two devices can connect to each other via Tailscale we are
already on the direct connection route instead of a relay / derp
connection?!
MarleTangible wrote 12 hours 22 min ago:
> It allows customers to make just one firewall exception for
connections only coming from their tailnet.
You'll need to open a single UDP port on your firewall, so it's your
public facing IP address. You don't need an entire VM somewhere, just
a single port.
Regarding the speed question. You'd use the derp when it's not
possible to make a peer to peer connection, which limits your speed
to derp server's speed and load. Which the peer relay, you can
practically use the entire bandwidth you have between your devices.
moontear wrote 10 hours 58 min ago:
> for connections coming from their tailnet
So instead of whitelisting all ports from IP range 100.64.0.0/10 I
would just whitelist e.g. UDP port 12345 coming from IP range
100.64.0.0/10 to my public IP? Or just open up UDP 12345
completely?
mintflow wrote 6 hours 48 min ago:
I think you need open UDP 12345 to public internet, where the
Tailscale Disco protocol runs on that, which is the underlay
port.
max-privatevoid wrote 13 hours 4 min ago:
Why go through the effort of reimplementing all this instead of using
libp2p?
asmor wrote 12 hours 59 min ago:
You mean the library that almost got me banned from my VPS provider
because it dialed about half the RFC1918 space?
skeptrune wrote 13 hours 31 min ago:
Yay! Excited to see them building this in public.
I recall that tailscale DERP servers were always slow and made things
feel delayed when they had to be used as a relay.
aborsy wrote 13 hours 36 min ago:
Great! This feature made a lot of sense, and it took a long time.
Itâs like falling back to hub and spoke, except that the traffic is
end to end encrypted, and the middle node is used only when direct
connection is not possible, and for some clients. Itâs also similar
to running your own derp server (which works also in TCP), but without
the hassle of doing so, and perhaps without having to open ports to the
internet (needed in derp) so long as the relay is reachable by peers.
The derp servers have low throughput. Another option could be a
pay-as-you-go derp service.
They might also be on their way to remove the need for reverse proxies,
with the recent announcement on Tailscale services.
BTW, why could it be paid for more than two relays? You are using just
your own devices and bandwidth :)
It actually lower the bandwidth bill for Tailscale by reducing the
usage of their own relays. Ideally, by default the software will find
whatever nodes could help with direct connection. Itâs just routing
within your own network.
MarleTangible wrote 12 hours 18 min ago:
> Itâs also similar to running your own derp server (which works
also in TCP), but without the hassle of doing so, and perhaps without
having to open ports to the internet (needed in derp) so long as the
relay is reachable by peers.
I think most folks will need to open a port to the internet, because
otherwise you wouldn't need the tailscale to begin with. e.g.
connecting your cloud network to your on premise network etc.
Of course exceptions apply, like both clients can reach the peer
relay, but not each other directly.
aborsy wrote 10 hours 57 min ago:
I could open a port to the internet, but it would be Tailscaleâs
responsibility to secure the software that listens to the port
(subject to an up-to-date software, that is my responsibility).
Itâs not a standard Wireguard port. With Wireguard included in
Linux, I would not be worried.
fukka42 wrote 13 hours 52 min ago:
> All customers can use two peer relays, for free, forever. As your
needs scale, so will the number of available peer relays. To add even
more peer relays to your tailnet, come have a chat with us.
I have to pay to be able to donate my own infra to make tailscale's
service better?
ssl-3 wrote 9 hours 1 min ago:
Your peer relays don't make Tailscale's infrastructure better.
They instead make your own infrastructure better.
Running a peer relay donates nothing to anyone.
fukka42 wrote 3 hours 15 min ago:
It makes their service better. It fixes slow transfer speeds
between my nodes because their derp servers are rate limited.
codethief wrote 13 hours 1 min ago:
> to make tailscale's server better?
While I don't think that's accurate, I, too, am surprised that this
feature isn't¹ completely free. After all, it will make it easier
(or possible at all) for many people to use Tailscale.
¹) s/isn't/might not end up being. See
URI [1]: https://news.ycombinator.com/item?id=45751253
bradfitz wrote 13 hours 15 min ago:
Tailscale employee here.
I kinda doubt we'll end up charging for it (as it costs us ~nothing
except support costs, which are real), but it's easier to make it
free later when it's GA rather than rug pull on people and start
charging for it in the future if we start it out free+unlimited.
Deathmax wrote 13 hours 57 min ago:
I can finally tear down my custom DERP server that I was using to get
higher throughput between two NAT'd clients.
zerkten wrote 14 hours 3 min ago:
What's the use case for this? It seems to be for situations where you
might have a SaaS product, but there is some data required from a
customer system. You'd expose the customer data using this relay and
integrate into the SaaS. Is that the gist of it? Integration would
still likely involve you giving the customer some software to expose a
limited API and handle auth, logging, etc.
ssl-3 wrote 12 hours 0 min ago:
Tailscale is a few things. It might be fair to say that it is mostly
a software platform with a web frontend that allows orgs (and
individual users alike) to easily create secure VPNs, so their
various systems can have a secure, unfiltered virtual private network
on which to communicate with eachother even if they're individually
scattered across the four corners of the Internet.
The usual (traditional) way to do VPN stuff is/was hub-and-spoke:
Each system connected to a central hub, and through that hub each
system had access to the other systems.
But the way that Tailscale operates is different than that: Ideally,
each connected system forms a direct UDP/IP connection with every
other system on the VPN. There is no hub. In this way: If node A
has data to send to node F, then it can send it directly there
without traversing through a central hub.
And that's pretty cool -- this peer-to-peer arrangement is gloriously
efficient compared to hub-and-spoke. (It's efficient enough that a
person can get quite a lot done with Tailscale for free, with no
payment expected ever.)
But we don't live in an ideal world. We instead often live in a
world of NAT and firewalls -- sometimes even implemented by the ISPs
themselves -- that can make it impossible for two nodes to directly
send UDP packets to eachother. This results in unreachable nodes,
which is not useful.
So Tailscale's workaround to that Internet problem is to provide
Designated Encrypted Relays for Packets (DERP). DERP usually works,
and end-to-end encryption is maintained.
DERP is also not at all new. It brings back some aspects of
hub-and-spoke, but only for nodes that can't communicate directly;
DERP behaves in a way akin to a hub, to help these crippled nodes by
relaying traffic between them and the rest of the VPN's nodes.
But DERP is a Tailscale-hosted operation. And it can be pretty slow
for some applications. And there was no way, previously, for an
individual user to improve the performance of DERP: It simply was
whatever it was -- with a collection of DERP servers chewing through
bandwidth to provide connectivity for a world of badly-connected VPN
nodes.
But today's announcement brings forth Tailscale Peer Relay.
> What's the use case for this?
The primary use case for this is simple: It is an alternative to
DERP. A user can now provide their own relay service for their
network's badly-connected peers to use. So now, rather than being
limited to whatever bandwidth DERP has available, relaying can offer
as much bandwidth as a user can afford to pay for and host
themselves.
And if a user plans it right, then they can put their Peer Relay
somewhere on the network where it can help minimize inter-node
latency compared to DERP.
(It's not for everyone. Tailscale isn't for everyone, either -- not
everyone needs a VPN at all. I'd never expect a random public
customer to use it knowingly and directly.)
bigstrat2003 wrote 10 hours 2 min ago:
Yeah, Tailscale is really cool. The only thing I wish is that they
didn't tie auth to either a big tech monopoly (Google, github etc)
or running your own IDP service. I would love to use Tailscale for
some self hosted stuff I have, but hesitate to start exposing
something like an identity management tool because that's a high
value target. And of course, I don't really want to let Google et
al be in control of my VPN setup either.
bilinguliar wrote 1 hour 0 min ago:
They support Passkeys. This is exactly how I continue using them
after moving away from Google Workspaces.
ssl-3 wrote 9 hours 22 min ago:
That's a valid concern.
I've also used ZeroTier with good success.
They're a competitor that offers VPN with similar idealized P2P
topology. Unlike Tailscale, ZT is not based on wireguard (ZT
predates wireguard), but they do offer the option to use their
own local auth without reliance/potential issues with yet-another
party.
ZT also allows a person to create and use their own relay (called
a "moon"), if that's something useful: [1] (For my own little
purposes I don't really have a preference between either Zerotier
or Tailscale.)
URI [1]: https://rayriffy.com/garden/zerotier-moon
bigstrat2003 wrote 7 hours 23 min ago:
Thanks for the tip! I'll check that out and see if it would
work for my VPN needs, but it certainly sounds promising.
smashed wrote 13 hours 51 min ago:
They are an alternative to the tailscale operated DERP servers, which
are cloud relays.
Even with the much touted NAT punching capabilities of tailscale,
there are numerous instances where tailscale cannot establish a true
p2p connection. The last fallback is the quite slow DERP relay and
from experience it gets used very often.
If you have a peer in your tailscale network that has a good
connection and that maybe you can even expose to the internet with a
port forward on your router, you now have this relay setting that you
can enable to avoid using the congested/shared DERP servers. So
there is not really a new use-case for this. It's the same, just
faster.
jsmeaton wrote 9 hours 40 min ago:
Is there a way to determine if a particular connection is falling
back to DERP today?
I have a pretty basic setup with tailscale setup on an Apple TV
behind a bunch of UniFi devices and occasionally tunnelled traffic
is incredibly slow.
Wondering if itâs worth setting this up on my Plex server which
is behind fewer devices and has a lot of unused network and cpu.
vachina wrote 4 hours 42 min ago:
tailscale ping
It will tell you how each ping has been answered until a direct
connection is established.
danudey wrote 13 hours 42 min ago:
The explanation that I think wasn't entirely clear in the post is
how it actually works/why that's better.
From what I can tell, the situation is this:
1. You have a host behind NAT
2. That NAT will not allow you to open ports via e.g. uPnP (because
it's a corporate firewall or something, for example) so other
tailscale nodes cannot connect to it
3. You have another host which has the same configuration, so
neither host can open ports for the other to connect in
The solution is to run a peer relay, which seems to be another (or
an existing) tailscale node which both of these hosts can connect
to via UDP, so in this circumstance it could be a third node you're
already running or a new one you configure on a separate network.
When the two NAT'ed hosts can't connect to each other, they can
both opt to connect instead to this peer node allowing them to
communicate with each other via the peer node.
Previously this was done via Tailscale's hosted DERP nodes; these
nodes would facilitate tailscale nodes to find each other but could
also proxy traffic in this hard-NAT circumstance. Now you can use
your own node to do so, which means you can position it somewhere
that is more efficient for these two nodes to connect to and where
you have control over the network, the bandwidth, the traffic, etc.
rcarmo wrote 14 hours 38 min ago:
OK, another use for port 1337. Anyone got a better, mnemonically
memorable choice in the low range?
neodymiumphish wrote 11 hours 27 min ago:
I'm using 3377 (D-E-R-P) since it's effectively replacing the DERP
servers on the specified source devices.
xeonmc wrote 14 hours 42 min ago:
I wonder if the next step could be to have all tailscale clients
automatically able to accept forwarding requests between any two
machines within the tailnet, so that the mesh seamlessly auto-routes
around any breaks within the mesh?
LunaSea wrote 9 hours 21 min ago:
Since the latency would be higher due to the additional hops or
distance, I wonder if it's not better to make the request crash so
that the issue is clearly detected rather than to continue in a
degraded but "invisible" state.
huhtenberg wrote 14 hours 22 min ago:
Yeah, such extension is natural and it comes up frequently in the
context of overlay networks. The defining question here is if you are
OK with relaying other people's CP traffic.
VikingCoder wrote 14 hours 17 min ago:
"within the tailnet." So, the "other people" are people you've
authorized to be on your tailnet, at least in this conversation.
homebrewer wrote 14 hours 55 min ago:
This was better solved by tinc about 20 years ago. All tinc nodes can
work as relays (but you can disallow that if you want), it does not
rely on a centralized server, and works fine without access to the
internet. It is a true mesh. The world would be better served by
porting tinc to wireguard and some memory safe language instead of
reimplementing parts of its functionality from scratch.
progval wrote 13 hours 41 min ago:
Heh. I have a 30-nodes Tinc network over the internet but some hosts
are behind a NAT. It keeps randomly losing routes between these
nodes. It even has the infuriating behavior that often it loses the
route a few seconds after I successfully established a SSH
connection.
Also, traffic seems to be decrypted and re-encrypted by relaying
nodes. For end-to-end encryption, you need "ExperimentalProtocol =
yes" added by Tinc 1.1, which was never formally released.
I'd like to rewrite something like it in a language I'm familiar with
(perhaps based on cjdns' protocol which is better documented than
Tinc's) but it's not easy.
0x696C6961 wrote 14 hours 47 min ago:
Wireguard can do what you're describing.
int0x29 wrote 14 hours 29 min ago:
Wireguard can't punch through NATs or firewalls without third party
software like Tailscale. Also I'm pretty sure each peer to peer
connection needs to be individually set up in a config file ahead
of time
vidarh wrote 9 hours 27 min ago:
It punches through my NAT just fine without third party software.
It's not as simple to make it reliable as it is with Tailscale,
but it works
It doesn't universally work without a helper script and a STUN
server, though - you need a suitably "friendly" NAT that has
reasonably predictable behaviour with respect to port mapping
and/or just one side of each pair behind a NAT.
conradev wrote 11 hours 23 min ago:
Folks have solved these problems and open sourced solutions: [1]
But all that I've seen are still centralized/federated
URI [1]: https://github.com/tonarino/innernet
bschwindHN wrote 4 hours 50 min ago:
(I help maintain innernet)
We have _some_ NAT traversal logic in place, but it's very
basic. Tailscale does a much more thorough job on it. It would
be cool to add peer relays to innernet but I imagine it's a
fair amount of work.
From what I recall, tailscale has their own Wireguard
implementation so they have more control over the socket and
how things are routed. innernet is just a wrapper around
managing wireguard peer lists, and yeah there's a central
coordination server which is unfortunate. If the server goes
down, you can still connect to peers so thankfully it doesn't
bring down your whole network, but you won't be able to learn
about new peers or peer endpoints over time until you
re-establish connectivity with the coordination server.
akerl_ wrote 11 hours 32 min ago:
Neither can tinc.
yardstick wrote 10 hours 16 min ago:
Last I checked, tinc supported NAT port punching natively.
akerl_ wrote 10 hours 12 min ago:
As far as Iâm aware, that works the same as things like
tailscale is doing, where you need at least one node that is
publicly reachable to facilitate.
yardstick wrote 8 hours 38 min ago:
Correct. This is not something Wireguard does, which was
the original comparison.
tinc: One public node, thousands of private nodes, with NAT
punching. That's fine and typical in my experience.
Dylan16807 wrote 8 hours 41 min ago:
Which is a much smaller requirement than needing extra
software on every NATed node.
So yes it is a differentiated thing between wireguard and
tinc, as you phrased it in your other comment.
blueflow wrote 11 hours 7 min ago:
... because its an problem with NAT and not with the protocol.
akerl_ wrote 10 hours 13 min ago:
Yes. Iâm replying to a comment thread debating WireGuard vs
tinc where someone said that WireGuard couldnât, as if it
was a differentiated thing between them.
qwertox wrote 13 hours 4 min ago:
A $2.5/month vps solves this issue.
1vuio0pswjnm7 wrote 4 hours 32 min ago:
Yes. Only use it as rendezvous server for publishing port
numbers and establishing direct connections. Do not use for
passing traffic
sneak wrote 7 hours 33 min ago:
It does not. I push hundreds of TB across my private mesh.
HowardStark wrote 13 hours 52 min ago:
Nebula[0] addresses this and is IMO an improvement over
WireGuard. Came out of Slack originally, and it supports peer
discovery, NAT hole punching, and some other cool features. Also
still uses the Noise Protocol.
In practice, the extra networking features + better first class
peer config management baked in is very nice (Nebulaâs
âlighthousesâ are configured with a tool similar to DSNet for
Wireguard[1])
[0] [1]
URI [1]: https://github.com/slackhq/nebula
URI [2]: https://github.com/naggie/dsnet
greenavocado wrote 3 hours 59 min ago:
What's the story with removing uncooperative endpoints from
Nebula?
sneak wrote 7 hours 33 min ago:
I use Nebula but the relay config is somewhat clunky and the
macOS port is pretty buggy.
halJordan wrote 11 hours 47 min ago:
So now we're back "tailscale but with different steps"
justahuman74 wrote 3 hours 9 min ago:
tailscale appears to be a paid product with a free tier,
nebula (while DIY) is free
HexDecOctBin wrote 15 hours 0 min ago:
Hard to parse the networking jargon, but does this enable offline
connections?
If I have two devices on my local LAN (both connected to a Tailnet) and
my home internet goes, currently the devices disconnect from each
other. I have been looking for a way to prevent that, so that the all
devices connected to the same WiFi network on a tailnet can find each
other even if the internet connection to the wider world is broken.
the8472 wrote 13 hours 59 min ago:
That'd be easy if only wireguard supported multiple endpoints per
peer, then one could add the ULA address of the local devices in
addition to the external one.
nirav72 wrote 14 hours 52 min ago:
> my home internet goes, currently the devices disconnect from each
other.
You might be able to solve this by hosting your own control plane
such as Headscale. Instead of having Tailscale manage/coordinate all
the nodes on tailnet.
URI [1]: https://github.com/juanfont/headscale
sampullman wrote 14 hours 14 min ago:
I ran headscale for a while and can confirm local devices could
still chat when the internet went down.
bananapub wrote 14 hours 58 min ago:
that already works
HexDecOctBin wrote 14 hours 53 min ago:
Not for me. Maybe some misconfiguration on my part then.
justinsaccount wrote 14 hours 0 min ago:
run `tailscale status` and ensure that your local machines are
connected to each other `direct` and not using a relay.
liuliu wrote 15 hours 0 min ago:
How to do site-to-site traffic over Tailscale / WG encryption? From
preliminary testing, it seems have difficulty to saturate a 10Gbps
connection while plain HTTP (nginx) traffic does that fine. Of course
it should vary from CPU to CPU, but any tips how to improve that?
Ideally I would love to go over with encrypted traffic, although
everything is public, just one less thing need to be careful (in case
future need to transport some non-public data over).
mh- wrote 14 hours 15 min ago:
You'd need to analyze what's bottlenecking when you're doing that.
Even a cursory look at htop on both ends while you're trying to
saturate that link would be informative.
cpressland wrote 15 hours 2 min ago:
I was literally looking for a solution for this over the weekend and
ended up with a very quirky setup for my Kubernetes Operator.
Now I can rip all that out and use this! Bravo!
ilmblover2 wrote 13 hours 46 min ago:
Man K8s is my nightmare haha. 100% agree
esseph wrote 4 hours 3 min ago:
K8s is a hell of a platform but it is a ... hell of a platform.
amluto wrote 15 hours 7 min ago:
How does this interact with machines that are shared from one Tailnet
to another? Is there specific syntax to grant the appropriate
permission to a user or device that accesses the destination via
sharing?
The docs also say:
> As a rule of thumb, the src devices in the grant policy should
typically be devices in a stable physical location behind a strict NAT
or firewall that prevents direct connections. This typically includes
devices in corporate networks or cloud environments. It usually does
not include mobile devices or laptops that frequently change locations
and network conditions.
Is there some reason that one should not set up a peer relay to enable
a laptop to access a machine that is behind a NAT? (Tailscale
regularly fails to establish direct connectivity from a laptop behind a
NAT to a machine that's behind a different NAT, at least in my
experience.)
kabirx wrote 14 hours 21 min ago:
One limitation of custom DERP is that across tailnets, they don't
share the same DERP maps and don't have access to each others' DERPs.
With Tailscale Peer Relays, the available relay bindings can be seen
by the devices on either side of a connection; as such it should work
out of the box with a sharing relationship between tailnets.
karaziox wrote 14 hours 47 min ago:
In your example the src would be the "machine that is behind a NAT".
That's the one the peer relay enable access to. And then all your
other devices (that laptop) can reach it through the peer relay.
I was also a bit confused on the meaning of src/dst in the grants.
The naming didn't match my thinking.
amluto wrote 14 hours 32 min ago:
Hmm. It would be very nice if this worked when the laptop is on a
different tailnet.
conradludgate wrote 14 hours 48 min ago:
My reading of the docs suggests that the relays and both peers must
be in the same tailnet. Additionally, both peers must have the
correct ACLs set up to access each other
DIR <- back to front page