[HN Gopher] Tailscale Peer Relays
___________________________________________________________________
Tailscale Peer Relays
Author : seemaze
Score : 348 points
Date : 2025-10-29 16:21 UTC (1 days ago)
(HTM) web link (tailscale.com)
(TXT) w3m dump (tailscale.com)
| amluto wrote:
| 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 wrote:
| 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 wrote:
| 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:
| Hmm. It would be very nice if this worked when the laptop is
| on a different tailnet.
| kabirx wrote:
| 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.
| cpressland wrote:
| 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:
| Man K8s is my nightmare haha. 100% agree
| esseph wrote:
| K8s is a hell of a platform but it is a ... hell of a
| platform.
| liuliu wrote:
| 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:
| 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 wrote:
| 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 wrote:
| that already works
| HexDecOctBin wrote:
| Not for me. Maybe some misconfiguration on my part then.
| justinsaccount wrote:
| run `tailscale status` and ensure that your local machines
| are connected to each other `direct` and not using a relay.
| nirav72 wrote:
| > 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
| sampullman wrote:
| I ran headscale for a while and can confirm local devices
| could still chat when the internet went down.
| the8472 wrote:
| 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 wrote:
| 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 wrote:
| Wireguard can do what you're describing.
| int0x29 wrote:
| 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 wrote:
| 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 [1]
| https://github.com/naggie/dsnet
| halJordan wrote:
| So now we're back "tailscale but with different steps"
| justahuman74 wrote:
| tailscale appears to be a paid product with a free tier,
| nebula (while DIY) is free
| dvtkrlbs wrote:
| there is an open source control plane called headscale
| which covers almost all of the features for free (while
| DIY)
| embedding-shape wrote:
| People keep saying that, but haven't we learned already
| that eventually Tailscale gets bought, then priorities
| change, then they make incompatible changes because
| they're need to grow, and headscale either can't keep up,
| or gets pushed away by Tailscale themselves, and we're
| back to using $TailscaleCompetitor who promises to not do
| the same thing.
|
| Just don't rely on centralized for-profit entities, rely
| on stuff produced by non-profits and foundations, that
| you know isn't gonna screw you over as soon as they need
| money.
| Capricorn2481 wrote:
| While I agree in spirit, I find this logic around for
| profit FOSS projects a little backwards sometimes,
| because it implies forking Tailscale wouldn't save much
| time.
|
| What makes you think we'd be better off building a
| competitor to something open source if it has all the
| features we want now? The reason we don't see open source
| competitors to big products is not because people are too
| dumb to try it. It's because it's way, way harder. It
| makes way more sense to Fork and work from there while
| we're still getting this momentum from Tailscale.
|
| If you think Headscale is going to have problems keeping
| up with a private Tailscale, good luck rebuilding
| Tailscale.
| drio wrote:
| > Just don't rely on centralized for-profit entities,
| rely on stuff produced by non-profits and foundations,
| that you know isn't gonna screw you over as soon as they
| need money
|
| What do you use that fits that philosophy and offers the
| basic functionality (NAT traversal, Magic DNS, failover
| relaying) TS provides?
| sneak wrote:
| I use Nebula but the relay config is somewhat clunky and
| the macOS port is pretty buggy.
| greenavocado wrote:
| What's the story with removing uncooperative endpoints
| from Nebula?
| qwertox wrote:
| A $2.5/month vps solves this issue.
| sneak wrote:
| It does not. I push hundreds of TB across my private
| mesh.
| gajgajendra wrote:
| When networks get used for unethical or criminal
| workloads, reliability problems aren't the tooling's
| fault. A tiny VPS does the job fine for the rest of us.
| sneak wrote:
| What are you talking about? Nothing I am pushing across
| my mesh is unethical or criminal, from whence these
| baseless accusations?
| gottorf wrote:
| I assume the GP assumed that it was pirated media
| material.
|
| Hundreds of TB over what timeframe? It does seem like
| quite a bit of data.
| 1vuio0pswjnm7 wrote:
| Yes. Only use it as rendezvous server for publishing port
| numbers and establishing direct connections. Do not use
| for passing traffic
| akerl_ wrote:
| Neither can tinc.
| blueflow wrote:
| ... because its an problem with NAT and not with the
| protocol.
| akerl_ wrote:
| 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.
| yardstick wrote:
| Last I checked, tinc supported NAT port punching
| natively.
| akerl_ wrote:
| 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.
| Dylan16807 wrote:
| 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.
| yardstick wrote:
| 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.
| conradev wrote:
| Folks have solved these problems and open sourced
| solutions: https://github.com/tonarino/innernet
|
| But all that I've seen are still centralized/federated
| bschwindHN wrote:
| (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.
| vidarh wrote:
| 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.
| givinguflac wrote:
| My netgear pr460x supports WireGuard with NAT & firewall;
| granted it's not a consumer router.
| throwwgisgreat wrote:
| > Wireguard can't punch through NATs or firewalls without
| third party software like Tailscale.
|
| That's a false or incorrect statement, I've been using
| Wireguard and a cheap VPS (actually free on OCI) for
| several years, and with a cheap VPS at AWS Lightsail before
| that. No third party software in use at all. The only thing
| running on the VPS is Wireguard. The only thing running on
| my peers is Wireguard.
|
| > Also I'm pretty sure each peer to peer connection needs
| to be individually set up in a config file ahead of time
|
| That's how I do it but there are tools available to make it
| easy.
| progval wrote:
| 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.
| xeonmc wrote:
| 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 wrote:
| 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:
| "within the tailnet." So, the "other people" are people
| you've authorized to be on your tailnet, at least in this
| conversation.
| huhtenberg wrote:
| Ah, my bad. You are right, I missed that bit.
| LunaSea wrote:
| 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 wrote:
| OK, another use for port 1337. Anyone got a better, mnemonically
| memorable choice in the low range?
| neodymiumphish wrote:
| I'm using 3377 (D-E-R-P) since it's effectively replacing the
| DERP servers on the specified source devices.
| zerkten wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jsmeaton wrote:
| 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:
| tailscale ping <node IP>
|
| It will tell you how each ping has been answered until a
| direct connection is established.
| ssl-3 wrote:
| 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:
| 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.
| ssl-3 wrote:
| 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:
| https://rayriffy.com/garden/zerotier-moon
|
| (For my own little purposes I don't really have a
| preference between either Zerotier or Tailscale.)
| bigstrat2003 wrote:
| Thanks for the tip! I'll check that out and see if it
| would work for my VPN needs, but it certainly sounds
| promising.
| bilinguliar wrote:
| They support Passkeys. This is exactly how I continue using
| them after moving away from Google Workspaces.
| codethief wrote:
| Oh wow, I had totally missed this[0]! Is it possible to
| migrate an existing SSO account (with associated tailnet)
| to a passkey one?
|
| [0]: https://tailscale.com/blog/passkeys
| Deathmax wrote:
| I can finally tear down my custom DERP server that I was using to
| get higher throughput between two NAT'd clients.
| fukka42 wrote:
| > 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 wrote:
| 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 wrote:
| > to make tailscale's server better?
|
| While I don't think that's accurate, I, too, am surprised that
| this feature isn't1 completely free. After all, it will make it
| easier (or possible at all) for many people to use Tailscale.
|
| 1) s/isn't/might not end up being. See
| https://news.ycombinator.com/item?id=45751253
| ssl-3 wrote:
| 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:
| It makes their _service_ better. It fixes slow transfer
| speeds between my nodes because their derp servers are rate
| limited.
| aborsy wrote:
| 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:
| > 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:
| 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 wrote:
| 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 wrote:
| Why go through the effort of reimplementing all this instead of
| using libp2p?
| asmor wrote:
| You mean the library that almost got me banned from my VPS
| provider because it dialed about half the RFC1918 space?
| moontear wrote:
| 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:
| > 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:
| > 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:
| I think you need open UDP 12345 to public internet, where
| the Tailscale Disco protocol runs on that, which is the
| underlay port.
| MarleTangible wrote:
| 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.
| MarleTangible wrote:
| What I understood is similar to making any device
| accessible on the internet. You would need to open the UDP
| 12345 on your router and forward the traffic to your
| server.
|
| It sounds like each peer would first access the peer relay
| to coordinate how they could establish a direct point-to-
| point connection with each other.
| alanchen wrote:
| Any reason this is not supported on iOS/tvOS devices? Would love
| to make it work on my Apple TV!
| neodymiumphish wrote:
| 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
|
| So they would need to get the binary size smaller in order to
| implement this on iOS or Apple TV.
| fariszr wrote:
| 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:
| Just set the relay up as an exit node too
| apitman wrote:
| 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:
| (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:
| 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.
| depr wrote:
| 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:
| 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.
| elcritch wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| lukashahnart wrote:
| I love Tailwind and use it on all my devices, but I'm not sure I
| really understand what this is.
| snapplebobapple wrote:
| Tailscale playing catchup to netbird...
| kkapelon wrote:
| What is the equivalent feature of netbird? Can you link the
| documentation please?
| ksynwa wrote:
| 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#rela...
| mercutio2 wrote:
| 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 wrote:
| 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 wrote:
| Doesn't Libp2p do this relay stuff already? Like, its their core
| model (and their NAT code is limited.)
| chaz6 wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-30 23:02 UTC)