9 ms·

Tailscale Peer Relays

364 points by seemaze 1y ago

cpressland 1y 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 1y ago
  Man K8s is my nightmare haha. 100% agree
  - esseph 1y ago
    K8s is a hell of a platform but it is a ... hell of a platform.
amluto 1y 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.)
- conradludgate 1y 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
- karaziox 1y 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 1y ago
    Hmm. It would be very nice if this worked when the laptop is on a different tailnet.
- kabirx 1y 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.
liuliu 1y 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- 1y 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.
HexDecOctBin 1y 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.
- bananapub 1y ago
  that already works
  - HexDecOctBin 1y ago
    Not for me. Maybe some misconfiguration on my part then.
    - justinsaccount 1y ago
      run `tailscale status` and ensure that your local machines are connected to each other `direct` and not using a relay.
- nirav72 1y 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. https://github.com/juanfont/headscale https://github.com/juanfont/headscale
  - sampullman 1y ago
    I ran headscale for a while and can confirm local devices could still chat when the internet went down.
- the8472 1y 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.
homebrewer 1y 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.
- 0x696C6961 1y ago
  Wireguard can do what you're describing.
  - int0x29 1y 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
    - HowardStark 1y 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] https://github.com/slackhq/nebula https://github.com/slackhq/nebula [1] https://github.com/naggie/dsnet https://github.com/naggie/dsnet
      - halJordan 1y ago
        So now we're back "tailscale but with different steps"
        justahuman74 1y ago
        tailscale appears to be a paid product with a free tier, nebula (while DIY) is free
xeonmc 1y 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?
- huhtenberg 1y 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 1y ago
    "within the tailnet." So, the "other people" are people you've authorized to be on your tailnet, at least in this conversation.
    - huhtenberg 1y ago
      Ah, my bad. You are right, I missed that bit.
- LunaSea 1y 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.
rcarmo 1y ago
OK, another use for port 1337. Anyone got a better, mnemonically memorable choice in the low range?
- neodymiumphish 1y ago
  I'm using 3377 (D-E-R-P) since it's effectively replacing the DERP servers on the specified source devices.
syahlanahda 1y ago
[flagged]
zerkten 1y 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.
- smashed 1y 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.
  - danudey 1y 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.
Deathmax 1y ago
I can finally tear down my custom DERP server that I was using to get higher throughput between two NAT'd clients.
fukka42 1y 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?
- bradfitz 1y 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.
- codethief 1y 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 https://news.ycombinator.com/item?id=45751253 https://news.ycombinator.com/item?id=45751253
- ssl-3 1y 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 1y ago
    It makes their service better. It fixes slow transfer speeds between my nodes because their derp servers are rate limited.
selasa67118 1y ago
[flagged]
aborsy 1y 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 1y 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 1y 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.
skeptrune 1y 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.
max-privatevoid 1y ago
Why go through the effort of reimplementing all this instead of using libp2p?
- _cenw 1y ago
  You mean the library that almost got me banned from my VPS provider because it dialed about half the RFC1918 space?
moontear 1y 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 1y 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 1y 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 1y ago
      I think you need open UDP 12345 to public internet, where the Tailscale Disco protocol runs on that, which is the underlay port.
      - MarleTangible 1y ago
        I would assume you only need to make sure that the other clients can access the UDP port, so not like public internet in the sense of 0.0.0.0/0 but just accessible by other peers, whatever their public facing IP addresses will be.
alanchen 1y ago
Any reason this is not supported on iOS/tvOS devices? Would love to make it work on my Apple TV!
- neodymiumphish 1y 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. https://developer.apple.com/documentation/networkextension https://developer.apple.com/documentation/networkextension So they would need to get the binary size smaller in order to implement this on iOS or Apple TV.
fariszr 1y 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 1y ago
  Just set the relay up as an exit node too
apitman 1y 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 1y 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 1y 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.
    - raggi 1y ago
      True, the relays currently use http and have a web socket path. The web based ssh client in the admin panel uses this transport.
depr 1y 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 1y 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.
  - kabirx 1y ago
    (Tailscalar here) We're taking this kind of outage very seriously. In particular this outage meant newly connected devices couldn't reliably reach our control plane and couldn't get the latest network state. IMO that's not okay. One of Tailscale's fundamental promises is that we want to try as much as possible to get our control plane and infrastructure as out of the way of your connectivity paths, while still using our infra to "assist" when there's connectivity issues (like difficult to traverse NAT), and maintain trust across the network, and keep everything up to date. It's a tough balance and this year we're dedicating resources to making sure even small blips in our control plane don't mean temporary losses of connectivity across even your newly woken up devices. In particular we're taking a multi-pronged approach, right now. We're working in parallel to increase client tolerance of control outages (in response to cracks shown in this incident) and have an ongoing effort to make the control plane more resilient and available.
elcritch 1y 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.
- rainsford 1y ago
  I've used ZeroTier in the past and I don't recall a feature similar to this being part of their offering. What I do remember is home brewed crypto, incredibly poor single threaded performance, and a glacial development pace. Any thread about Tailscale inevitably brings up alternatives, but having tried many of them in the past, I've yet to find one that actually competes across all the features and performance. The comparisons to other solutions tend to give me "why do you need Dropbox when FTP exists?" vibes.
  - elcritch 1y ago
    It's not clear to me if it's different than Zerotier's routing design or not. Partly because ZT has their "moons" and custom network controllers. Googling about it does seem to indicate ZT doesn't support peers routing traffic directly, but you can setup your own DERP style TCP relays. To me Tailscale is just a nicer version of Zerotier but not in different genre like ftp vs Dropbox. From a general non-power users perspective they operate almost identically.
  - alexjurkiewicz 1y ago
    ZeroTier supports relaying natively. You create a network with three nodes, the "client" (on the internet), the "gateway" (public subnet) and the "server" (private subnet). ZeroTier will automatically route traffic between the client and server through your gateway with no configuration.
lukashahnart 1y ago
I love Tailwind and use it on all my devices, but I'm not sure I really understand what this is.
snapplebobapple 1y ago
Tailscale playing catchup to netbird...
- kkapelon 1y ago
  What is the equivalent feature of netbird? Can you link the documentation please?
  - ksynwa 1y ago
    I couldn't find a specialised page for it. But here they mention that the relay service can be self hosted: https://docs.netbird.io/about-netbird/how-netbird-works#relay-service https://docs.netbird.io/about-netbird/how-netbird-works#rela...
  - snapplebobapple 1y ago
    It's using a turn server to provide the DERP feature (in the case of the quick setup it's coturn but you can use other turn servers). So to create this you just set up more turn servers and add them. It's fairly simple.
mercutio2 1y 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.
- MezzoDelCammin 1y ago
  mind developping on the "it's DERP or nothing"? Have you been trying to expose a direct wireguard port of your own, or the Tailscale?
Uptrenda 1y ago
Doesn't Libp2p do this relay stuff already? Like, its their core model (and their NAT code is limited.)
chaz6 1y ago
Is it possible to specify the external ipv4 and ipv6 address? There are scenarios where the eggress traffic uses a different address to ingress, or the host has multiple internet-connected addresses but only one has a firewall permitting traffic to the nominated port.
viaoktavia 1y ago
[dead]
damnever 1y ago
Really nice move, just speed and simplicity.
johntash 1y ago
(in)convenient timing. I just recently implemented a mesh network using wireguard+bgp so that all nodes can connect to each other one way or another. This would have probably been a lot easier for almost the same result.

364 points by seemaze 1y 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 1y ago
Man K8s is my nightmare haha. 100% agree
- esseph 1y ago
  K8s is a hell of a platform but it is a ... hell of a platform.

amluto 1y 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.)

conradludgate 1y 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
karaziox 1y 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 1y ago
  Hmm. It would be very nice if this worked when the laptop is on a different tailnet.
kabirx 1y 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.

liuliu 1y 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- 1y 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.

HexDecOctBin 1y 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.

bananapub 1y ago
that already works
- HexDecOctBin 1y ago
  Not for me. Maybe some misconfiguration on my part then.
  - justinsaccount 1y ago
    run `tailscale status` and ensure that your local machines are connected to each other `direct` and not using a relay.
nirav72 1y 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. https://github.com/juanfont/headscale https://github.com/juanfont/headscale
- sampullman 1y ago
  I ran headscale for a while and can confirm local devices could still chat when the internet went down.
the8472 1y 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.

homebrewer 1y 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.

0x696C6961 1y ago
Wireguard can do what you're describing.
- int0x29 1y 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
  - HowardStark 1y 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] https://github.com/slackhq/nebula https://github.com/slackhq/nebula [1] https://github.com/naggie/dsnet https://github.com/naggie/dsnet
    - halJordan 1y ago
      So now we're back "tailscale but with different steps"
      - justahuman74 1y ago
        tailscale appears to be a paid product with a free tier, nebula (while DIY) is free

xeonmc 1y 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?

huhtenberg 1y 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 1y ago
  "within the tailnet." So, the "other people" are people you've authorized to be on your tailnet, at least in this conversation.
  - huhtenberg 1y ago
    Ah, my bad. You are right, I missed that bit.
LunaSea 1y 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.

rcarmo 1y ago

OK, another use for port 1337. Anyone got a better, mnemonically memorable choice in the low range?

neodymiumphish 1y ago
I'm using 3377 (D-E-R-P) since it's effectively replacing the DERP servers on the specified source devices.

syahlanahda 1y ago

[flagged]

zerkten 1y 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.

smashed 1y 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.
- danudey 1y 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.

Deathmax 1y ago

I can finally tear down my custom DERP server that I was using to get higher throughput between two NAT'd clients.

fukka42 1y 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?

bradfitz 1y 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.
codethief 1y 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 https://news.ycombinator.com/item?id=45751253 https://news.ycombinator.com/item?id=45751253
ssl-3 1y 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 1y ago
  It makes their service better. It fixes slow transfer speeds between my nodes because their derp servers are rate limited.

selasa67118 1y ago

[flagged]

aborsy 1y 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 1y 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 1y 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.

skeptrune 1y 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.

max-privatevoid 1y ago

Why go through the effort of reimplementing all this instead of using libp2p?

_cenw 1y ago
You mean the library that almost got me banned from my VPS provider because it dialed about half the RFC1918 space?

moontear 1y 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 1y 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 1y 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 1y ago
    I think you need open UDP 12345 to public internet, where the Tailscale Disco protocol runs on that, which is the underlay port.
    - MarleTangible 1y ago
      I would assume you only need to make sure that the other clients can access the UDP port, so not like public internet in the sense of 0.0.0.0/0 but just accessible by other peers, whatever their public facing IP addresses will be.

alanchen 1y ago

Any reason this is not supported on iOS/tvOS devices? Would love to make it work on my Apple TV!

neodymiumphish 1y 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. https://developer.apple.com/documentation/networkextension https://developer.apple.com/documentation/networkextension So they would need to get the binary size smaller in order to implement this on iOS or Apple TV.

fariszr 1y 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 1y ago
Just set the relay up as an exit node too

apitman 1y 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 1y 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 1y 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.
  - raggi 1y ago
    True, the relays currently use http and have a web socket path. The web based ssh client in the admin panel uses this transport.

depr 1y 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 1y 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.
- kabirx 1y ago
  (Tailscalar here) We're taking this kind of outage very seriously. In particular this outage meant newly connected devices couldn't reliably reach our control plane and couldn't get the latest network state. IMO that's not okay. One of Tailscale's fundamental promises is that we want to try as much as possible to get our control plane and infrastructure as out of the way of your connectivity paths, while still using our infra to "assist" when there's connectivity issues (like difficult to traverse NAT), and maintain trust across the network, and keep everything up to date. It's a tough balance and this year we're dedicating resources to making sure even small blips in our control plane don't mean temporary losses of connectivity across even your newly woken up devices. In particular we're taking a multi-pronged approach, right now. We're working in parallel to increase client tolerance of control outages (in response to cracks shown in this incident) and have an ongoing effort to make the control plane more resilient and available.

elcritch 1y 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.

rainsford 1y ago
I've used ZeroTier in the past and I don't recall a feature similar to this being part of their offering. What I do remember is home brewed crypto, incredibly poor single threaded performance, and a glacial development pace. Any thread about Tailscale inevitably brings up alternatives, but having tried many of them in the past, I've yet to find one that actually competes across all the features and performance. The comparisons to other solutions tend to give me "why do you need Dropbox when FTP exists?" vibes.
- elcritch 1y ago
  It's not clear to me if it's different than Zerotier's routing design or not. Partly because ZT has their "moons" and custom network controllers. Googling about it does seem to indicate ZT doesn't support peers routing traffic directly, but you can setup your own DERP style TCP relays. To me Tailscale is just a nicer version of Zerotier but not in different genre like ftp vs Dropbox. From a general non-power users perspective they operate almost identically.
- alexjurkiewicz 1y ago
  ZeroTier supports relaying natively. You create a network with three nodes, the "client" (on the internet), the "gateway" (public subnet) and the "server" (private subnet). ZeroTier will automatically route traffic between the client and server through your gateway with no configuration.

lukashahnart 1y ago

I love Tailwind and use it on all my devices, but I'm not sure I really understand what this is.

snapplebobapple 1y ago

Tailscale playing catchup to netbird...

kkapelon 1y ago
What is the equivalent feature of netbird? Can you link the documentation please?
- ksynwa 1y ago
  I couldn't find a specialised page for it. But here they mention that the relay service can be self hosted: https://docs.netbird.io/about-netbird/how-netbird-works#relay-service https://docs.netbird.io/about-netbird/how-netbird-works#rela...
- snapplebobapple 1y ago
  It's using a turn server to provide the DERP feature (in the case of the quick setup it's coturn but you can use other turn servers). So to create this you just set up more turn servers and add them. It's fairly simple.

mercutio2 1y 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.

MezzoDelCammin 1y ago
mind developping on the "it's DERP or nothing"? Have you been trying to expose a direct wireguard port of your own, or the Tailscale?

Uptrenda 1y ago

Doesn't Libp2p do this relay stuff already? Like, its their core model (and their NAT code is limited.)

chaz6 1y ago

Is it possible to specify the external ipv4 and ipv6 address? There are scenarios where the eggress traffic uses a different address to ingress, or the host has multiple internet-connected addresses but only one has a firewall permitting traffic to the nominated port.

viaoktavia 1y ago

[dead]

damnever 1y ago

Really nice move, just speed and simplicity.

johntash 1y ago

(in)convenient timing. I just recently implemented a mesh network using wireguard+bgp so that all nodes can connect to each other one way or another. This would have probably been a lot easier for almost the same result.