[HN Gopher] Choose your own IP
       ___________________________________________________________________
        
       Choose your own IP
        
       Author : darthShadow
       Score  : 126 points
       Date   : 2023-12-07 17:29 UTC (5 hours ago)
        
 (HTM) web link (tailscale.com)
 (TXT) w3m dump (tailscale.com)
        
       | evntdrvn wrote:
       | Thank you to everyone at TS involved in this feature!! It will
       | solve a big pain point for us re reserved CGNAT ranges that were
       | causing conflicts. Cheers
        
       | wheybags wrote:
       | The one feature I feel is missing now is attaching to multiple
       | tailnets from the same client. Since you can configure address
       | ranges, I could set up non-overlapping ranges on my personal and
       | work tailnets, and then use both on my phone, for example.
        
       | arittr wrote:
       | "One thing you can rely on with IPv4: whatever the problem,
       | Network Address Translation is part of the solution."
       | 
       | NAT... the cause of, and solution to, all of life's problems.
        
         | BLKNSLVR wrote:
         | I thought it was always DNS?
        
           | H8crilA wrote:
           | I thought it's BGP? Or maybe that's just the cause of all
           | problems, hmm...
        
             | Affric wrote:
             | My understanding of BGP is that it's so old (and was
             | relatively well designed) that it could now be considered
             | an arcane magic once widespread but now only known by some
             | old wizards.
        
           | 0x457 wrote:
           | Yes, but it's also an issue with IPv6. NAT is nearly always
           | involved with whenever you touch IPv4.
        
       | AdamJacobMuller wrote:
       | > To address this (no pun intended),
       | 
       | Liars, you definitely did.
       | 
       | I was a bit surprised when I learned tailscale was addressing out
       | of a single global pool and wondered how they would fix it when
       | they ran out of IPs (and I knew they would, Tailscale was and is
       | obviously that good to me). I vaguely suspected this would be
       | kind of solution they would employ because it's really perfect
       | from an end-user experience point of view, but, thought they
       | might not because it's definitely more complex on their side.
       | Shame on me for misunderestimating the tailscale team.
        
         | hughesjj wrote:
         | Hot take: The Tailscale team is the highest concentration of
         | leading network engineers from any company in the world today,
         | at least when it comes to consumer products. If we ever get a
         | true 'next gen' internet that removes the protocol cruft we've
         | layered on over the years, I could see it coming out of them
         | moreso anyone else.
        
       | moduspol wrote:
       | I just set up Tailscale for work last week. I've been really
       | impressed with it.
        
         | MuffinFlavored wrote:
         | What does it give you that Wireguard doesn't (or OpenVPN)? Just
         | easier to configure + setup + a nice UI? Just making sure I'm
         | not missing something, not trying to knock Tailscale.
         | 
         | Do the "minimalist" people have good reason to prefer
         | "anything-else" other than "heavy feature-rich Tailscale"?
        
           | anderiv wrote:
           | For me the key additions are: 1) integration with our org
           | Identity Provider 2) NAT traversal + DERP relay fallback 3)
           | Tailscale's ACL functionality.
        
           | tptacek wrote:
           | Certainly, don't use OpenVPN in 2023 if you can avoid it.
           | WireGuard is much faster and more secure, and significantly
           | easier to set up.
           | 
           | If you're a home user, the advantage to Tailscale is that
           | it's going to "just work", with a couple clicks, on any
           | supported device (of which there are lots). There's no
           | configuration to get started and, for a lot of users, no
           | configuration ever after that. The onboarding experience is
           | spooky; it's _upsettingly_ good.
           | 
           | If you're a corporate user, the advantages are drastically
           | greater: you get SSO integration (this is historically one of
           | the annoying pain points of corporate access VPNs, to the
           | point where a significant fraction of pre-Tailscale netsec
           | teams just punted on this problem and hand-provisioned VPN
           | creds for people, which is a nightmare) and trivially simple
           | group-based access control.
        
             | mato wrote:
             | The combination of 'it just works' and 'SSO integration' is
             | a killer.
             | 
             | To be honest, in 20+ years of working in IT, I never
             | understood the point of the latter until recently, on a gig
             | salvaging systems for a client with ~650 users after their
             | sole IT guy unexpectedly resigned after 20 years and left
             | for the mountains.
             | 
             | IRL, SSO is gold. Many hackers, like me, underestimate it.
        
               | moduspol wrote:
               | And not just SSO, but OIDC. You don't even have to be an
               | admin on your domain to set it up. If you have a Gmail or
               | Office 365 e-mail address @mycorp.com, you can set up SSO
               | for it on your tailnet in seconds. Your team members
               | authenticating for the same domain will join your tailnet
               | automatically.
               | 
               | And that's for the free and cheap tier. If you want the
               | fancy stuff (like SAML and automatic user provisioning /
               | filtering), they've apparently got that, too, but it's in
               | the more expensive tiers.
        
             | 0xbadcafebee wrote:
             | Worth pointing out that "just use Wireguard" is way
             | different than "just use Tailscale". The latter has
             | solutions for common problems, the former is not even
             | remotely comparable feature-wise to OpenVPN. If the only
             | choice is between OpenVPN or Wireguard, often OpenVPN is
             | the only acceptable option, because it has all the features
             | you need.
        
           | zikduruqe wrote:
           | > What does it give you that Wireguard doesn't
           | 
           | Less battery life on your iPhone. :)
           | 
           | I have both in my home network and love both.
           | 
           | At work, I have used Tailscale in my Kubernetes clusters to
           | allow devs to get into the private subnets, so that is
           | awesome, and way better than trying to give a group wireguard
           | key pairs.
        
             | greenicon wrote:
             | Yes, the battery drain on iOS is also the thing stopping me
             | from having it on my iPhone. Wireguard is way better in
             | that regard, but has other issues (e.g. no split dns, no
             | dns re-resolve for dyndns or for network changes).
             | 
             | Other than that tailscale is really great. It just works.
        
               | zikduruqe wrote:
               | Yep, I have my Wireguard client connect when I am off my
               | network and I split DNS so I can continue to use my ad
               | blocker when off my network and on the macro network. For
               | that it is perfect.
        
           | xoa wrote:
           | > _What does it give you that Wireguard doesn 't (or
           | OpenVPN)? Just easier to configure + setup + a nice UI? Just
           | making sure I'm not missing something, not trying to knock
           | Tailscale._
           | 
           | I personally haven't deployed it though I've toyed with it,
           | but I think as well as UI and integrations a core topology
           | differentiator is that, like Nebula, Tailscale does/can do
           | meshing. Plain vanilla Wireguard is pure classic hub-and-
           | spoke, which is 100% fine for a basic VPN use case like "I'm
           | out somewhere on the WAN and want to talk to this LAN stuff"
           | or "I want to tunnel some/all my traffic through some
           | specific alternate exit".
           | 
           | But say you've got main site A which has a public static IP
           | and is where support is for administrating others, site B
           | which has a full backup server but no public IP, and then
           | sites C/D/E/etc where people are doing work and having
           | significant on-site storage and comms needs, all of which are
           | behind typical ISP NAT from multiple different ISPs with no
           | static IPs. Everyone wants to be able to do high bandwidth
           | things like video chat directly together, or back up/restore
           | to site B. Plain WG could do that, but would funnel it all
           | through site A's link which isn't very scalable and likely to
           | become a choke point in a hurry. A meshing VPN can let two
           | private sites talk directly with a public address only
           | serving to facilitate hole punching and setting up the
           | connection each time. It's definitely of real value. Another
           | thing would be not bandwidth but latency. If you're within a
           | few hundred miles on land that probably is irrelevant. But if
           | different sites/people are across continents adding an
           | unnecessary extra hop may become a very big deal even for
           | simple web apps. Resiliency also enters the equation, what if
           | site A goes down? A mesh can help with those too.
           | 
           | Then Tailscale adds a lot of cool QoL on top. Meshing does
           | raise new challenges in terms of access control vs when
           | everything is funneled through a single convenient point. But
           | regardless, other topologies can be of basic interest too
           | even without extra sugar.
        
             | megous wrote:
             | > Wireguard is pure classic hub-and-spoke
             | 
             | No it's not. You can do any to any just fine (and any
             | topology in between these extremes).
        
               | xoa wrote:
               | Nice job skipping the explicit qualifier of "plain
               | vanilla"? Being able to build your own version on top
               | isn't the same as an existing tested product.
        
           | moduspol wrote:
           | It does OIDC integration out-of-the-box and for their free
           | and cheap tiers. OIDC is like the "login with Google" stuff
           | that doesn't require any setup. So I was able to have SSO
           | setup immediately with our Office 365 domain without
           | bothering to setup SAML or anything.
           | 
           | The VPN clients for Mac and iOS are on the App Store, which
           | may not mean much, but having developed VPN apps for both,
           | what it means is: it is far less likely break or muck with
           | your OS's networking in practice because it's sandboxed and
           | can only use Apple's SDK for interfacing with the OS. This is
           | compared to every OpenVPN client I've used on various
           | platforms, which must run as root and often is setting up and
           | tearing things down with shell scripts that can get hairy as
           | you add more complexity / moving parts.
           | 
           | (Note that this is also true for Wireguard's client, just not
           | OpenVPN)
           | 
           | The first three users are always free, so we're able to demo
           | it easily. It's also listed on AWS marketplace, so as we move
           | to start buying some licenses, it's billed through our AWS
           | bill (i.e. I don't need an act of Congress to get a credit
           | card number entered and a new monthly invoice reconciled
           | within my company).
           | 
           | You can configure how often it forces reauthentication, which
           | is probably the biggest benefit over vanilla Wireguard.
           | Wireguard doesn't have mechanisms for expiring and replacing
           | keys, so it solves that.
           | 
           | There's also an open source implementation of the master
           | service (called headscale) that you can run on your own, and
           | I was able to fairly easily set it up and get the existing
           | Tailscale apps from the App Store to be reconfigured to
           | utilize.
           | 
           | Honestly it's the cleanest VPN experience I've had if you
           | need to deal with any kind of SSO and/or dynamic user/client
           | provisioning. If you're just setting up point-to-point
           | between a few of your own servers and clients that won't
           | change, maybe just stick to Wireguard. But once you start
           | needing anything more than that--I'd give Tailscale a shot
           | first.
        
           | tonyarkles wrote:
           | Yeah, I think "Just" is doing a lot of heavy lifting in that
           | question :)
           | 
           | I've never configured Wireguard from scratch but I have
           | managed an OpenVPN deployment in the past. One of the most
           | fabulous aspects of Tailscale is that it's very self-served;
           | we configured our Tailscale account to allow email addresses
           | from our main domain name with O365 integration. When someone
           | wants to bring a new node online, they log in with their O365
           | credentials and magically new keys are assigned to the node
           | and associated with the user who created them. In the past
           | with the OpenVPN deployment, it would usually take me 15-30
           | minutes to get a new node online (generating keys, getting
           | them handed off to the user, helping them debug, etc); now it
           | takes me 0 minutes because the user can just generate their
           | own keys and I can be completely hands off, while still
           | having a nice view that I can use to revoke keys if needed.
        
             | belval wrote:
             | To be fair, Wireguard is incredibly easier to setup and
             | maintain than OpenVPN, pretty much not comparable. I don't
             | know how easy it is with Tailscale though so I can't
             | comment as to how much harder Wireguard is compared to it.
        
           | tsujamin wrote:
           | My mum could probably install on her phone, and configure an
           | exit on her computer, without knowing what Wireguard or `-j
           | MASQUERADE` means ;)
        
           | wharvle wrote:
           | You can set it up on most of your devices, including mobile,
           | with a couple clicks/taps, and not having to read any
           | manpages. You can achieve having e.g. an Apple TV as a VPN
           | network gateway with similar ease.
           | 
           | A technical person who's familiar with what a VPN is and does
           | but has never configured one can have it working on a bunch
           | of their devices in like 30 minutes flat, with no notable
           | ongoing maintenance to worry about.
           | 
           | If you're already configuring your home networking with
           | Ansible or Helm or something, it's probably not a win.
        
           | freedomben wrote:
           | Tailscale is basically automation and
           | authentication/authorization and UI on top of Wireguard. You
           | could do it all manually, but you'll need to know the details
           | of how to configure raw wireguard exactly how you need it,
           | which for many people is above their heads. There are a _lot_
           | of things that tailscale automates, so you have to know a
           | great deal in order to configure a wireguard net yourself to
           | the equivalent
        
           | sleepybrett wrote:
           | https://tailscale.com/compare/wireguard/
           | 
           | Here is what I will say. I manually setup wireguard for my
           | home network, it was annoying but doable. Then when tailscale
           | started to get interesting I just decided try it out using a
           | free account and rolled back my wireguard configuration...
           | and never went back. It's so much less fiddly.
        
       | GauntletWizard wrote:
       | 1:1 Nat is a great solution... except in cases where IP Addresses
       | of peers are transmitted as part of the protocol, like in Gossip
       | structures or (Not that anyone should be using this!) FTP. Most
       | games do this, though explicitly to get around NAT so they
       | understand which packets are coming from where.
       | 
       | Honestly, in none of my use-cases will it matter - I can't see
       | myself running a gossip protocol across servers that I do and
       | don't control.
        
       | jakedata wrote:
       | I hope they are working on improving firewall traversal. Lots of
       | firewalls don't allow symmetrical UDP NAT ports, causing clients
       | to fall back to DERP relays on TCP port 443. It's a lot slower.
       | It is possible to work around this by statically mapping inbound
       | UDP ports but that is clearly not an ideal situation. I generally
       | love Tailscale though, amazing work all around.
        
         | incahoots wrote:
         | Oh I wasn't aware of this, thanks for sharing this.
        
         | wtatum wrote:
         | Do you know of a straightforward way to identify that this is
         | happening: where one node is using DERP or one link between
         | your nodes is falling back to DERP?
        
           | cassianoleal wrote:
           | `tailscale status` should tell you which nodes do or don't
           | have a direct connection.
        
       | incahoots wrote:
       | Tailscale is needed if you require site to site connectivity via
       | something like Starlink.
       | 
       | I may be putting my ignorance on display here, but I recently
       | completed a site-to-site network between two farms in rural
       | America, no other ISP can serve these farms, and they needed to
       | communicate cow data between the different farms. Tailscale did
       | the majority of the heavy lifting thankfully, and we were able to
       | get them all sorted out.
       | 
       | I could not get Wireguard to work, and that may be down to my
       | limitations in networking, but I was sucessful with tailscale, so
       | make of that as you will.
        
         | howeyc wrote:
         | If I had to guess, it's probably the NAT hole-punching or use
         | of tailscale servers as an intermediary.
         | 
         | If you signed up for a $5 VPS to forward packets you probably
         | would have been fine.
        
           | toomuchtodo wrote:
           | Tailscale is free for 3 users and up to 100 devices, so it's
           | a fine solution vs running your own VM for hole punching.
           | Consider your time value. You can even pay for Mullvad exit
           | node access for devices in your net and configure the
           | coordination layer accordingly.
        
         | nijave wrote:
         | Looks like Starlink supports IPv6 but you'd probably want
         | dynamic DNS updater to keep a DNS record with the correct IP in
         | case it ever changes.
        
         | freedomben wrote:
         | Lack of Wireguard docs/tutorials is unfortunate, because I'm in
         | the same boat. I'm using Tailscale now because I just don't
         | know enough about linux networking to figure out why my packets
         | aren't going where they should. I suspect it's a very simple
         | config error, but I don't know how to debug or where to look. I
         | like Tailscale, but I'd much rather use real wireguard and
         | eliminate a dependency on tailscale, but I can't find
         | guides/tutorials/etc.
         | 
         | If anyone knows of a Wireguard walk-through to bridge two
         | separate LANs together, I'd love to see it
        
           | candiddevmike wrote:
           | Create a wireguard interface on each end, add the keys to
           | them, open up the allow list for each subnet, assign a IP
           | from a /30 (or /31) subnet on each end, set static routes to
           | point to other end or use a dynamic routing protocol.
           | 
           | There are tools to automate this like wg-quick and systemd-
           | networkd, depending on your preference.
        
           | drdaeman wrote:
           | > Lack of Wireguard docs/tutorials is unfortunate
           | 
           | The thing about Wireguard is that it's very simple and
           | minimal. It does just one thing, and that is - establishes a
           | layer 3 tunnel for sending IP packets between local machine
           | and some other peers. It doesn't do mesh, it doesn't do
           | routing (it just knows the IPs of its direct peers and that's
           | all it does), it doesn't do bridging - all this stuff is done
           | by other pieces such as Linux kernel, but not Wireguard
           | itself.
           | 
           | > Wireguard walk-through to bridge two separate LANs
           | 
           | Same or different subnets for those LANs? If they're
           | different and non-intersecting, and if you don't need cross-
           | LAN broadcast or multicast, the simplest option is to
           | establish a Wireguard connection between those LAN's default
           | gateway routers (assuming you can do this), and on each of
           | those routers set up a route that sends opposite LAN's
           | traffic to the opposite gateway (in case of iproute2: `ip
           | route add my.other.lan.subnet/mask via my.other.lan.gw`, how
           | to make this persistent depends on your distro). Then, on
           | each gateway, allow packet forwarding between Wireguard and
           | LAN interfaces (with e.g. iptables or nftables or whatever
           | you use there).
           | 
           | If you can't run Wireguard on gateways, the overall principle
           | holds, but you'll need to distribute routes to your
           | respective LANs via Wireguard-running routers through DHCP or
           | whatever you use for routing on your LANs (e.g. OSPF).
           | 
           | And if your LANs both have the same subnet, or if you need
           | multicast, things get significantly trickier (plus, there's
           | inevitable question of what should happen if two machines on
           | different LANs have the same IP). You'll probably need to run
           | something like L2TP or GRETAP (or something else that can
           | encapsulate you layer 2) over Wireguard.
           | 
           | Or maybe just use OpenVPN in TAP mode (if you want all stuff
           | independent of any third parties) or Tailscale (because it
           | already works).
        
             | hhh wrote:
             | The end of your comment "or use Tailscale" sums up why I
             | would use Tailscale here.
        
               | drdaeman wrote:
               | Of course. Picking a tool is always a matter of what one
               | already knows. If you've already learned Tailscale and it
               | fits all your requirements - that means you go with it,
               | unless you have some reasons not to do it (which is
               | rare).
               | 
               | And Tailscale surely has one benefit here - it's one
               | single product, with essentially no variations, so it's
               | (I presume, I haven't ever used Tailscale myself - never
               | needed it) easy to write a step-by-step instructions for.
               | Generic "GNU/Linux software router with Wireguard" is an
               | extremely vague target that impossible to give
               | instructions for, unless you spend a lot of time
               | describing the problem in finer detail.
        
           | rollcat wrote:
           | > I like Tailscale, but I'd much rather use real wireguard
           | and eliminate a dependency on tailscale, but I can't find
           | guides/tutorials/etc.
           | 
           | You could use Headscale, which is an open-source/self-hosted
           | reimplementation of Tailscale control plane, so you can eat
           | your cake and have it too.
           | 
           | Curious to know, why does distrust towards Tailscale come up
           | so often around here? They seem extremely transparent about
           | their strategy and incentives.
        
             | drdaeman wrote:
             | > Curious to know, why does distrust towards Tailscale come
             | up so often around here?
             | 
             | I have a guess - I suspect it's because in the domain it
             | addresses, attitudes are towards self-reliance, privacy and
             | autonomy.
             | 
             | If someone uses Tailscale in some cloudy (aka all someone
             | else's computers) setup, they probably don't bother. They
             | already shift trust and rely on other people.
             | 
             | But Tailscale is infrequently used to manage own devices,
             | which is why it clashes with self-reliance attitudes. If
             | you run your own private hardware and networks, all or many
             | of those in your own castle, it may bug you to introduce
             | (or I'd rather say trust) a third party unless you're
             | forced to. Not because it's not trustworthy, but because of
             | the self-reliance attitude and desire to have full control
             | over what you think of your own systems.
             | 
             | Sure, you're forced to trust your electricity provider (but
             | you have an UPS) or network uplink (and even then you make
             | security precaution), but trust in Tailscale is kind of
             | optional (it's not irreplaceable), and not everyone feel
             | like they want it.
             | 
             | Pretty much the same why a lot of people frown upon IoT
             | stuff, even if it's from rare vendors who go extra mile to
             | make things reliable - because of the hypothetical "but
             | what if?" and feeling that you're losing the control here.
             | 
             | Just a guess, though. Others' mileage may vary.
        
           | BonoboIO wrote:
           | On my synology ds418j Tailscale was faster than WireGuard
           | over the same interface. WireGuard used 30 to 50 percent more
           | cpu. Was strange, but not a real problem. Just an anecdote.
        
         | mschuster91 wrote:
         | > but I recently completed a site-to-site network between two
         | farms in rural America, no other ISP can serve these farms, and
         | they needed to communicate cow data between the different
         | farms.
         | 
         | This may be verging on off-topic, but it's too good an
         | opportunity to not deliver this very fitting reminder: in 2018
         | Anja Karliczek, then-Minister of Science of Germany, made
         | headlines for the quote "5G nicht an jeder Milchkanne
         | notwendig" [1] ("you don't need 5G on every milk jug") aka the
         | rural areas (that had been left behind even with prior mobile
         | phone/data and even landline DSL deployments) didn't have
         | enough need for fast Internet access.
         | 
         | So, to answer her question, what exactly are these farms doing
         | that they need to exchange cow metrics? Tracking of milk
         | production per cow?
         | 
         | [1] https://www.spiegel.de/politik/deutschland/anja-karliczek-
         | br...
        
         | 0x457 wrote:
         | I don't think you need Tailscale for this.
         | 
         | You need tailscale when:
         | 
         | 1) You have a lot of road-warriors
         | 
         | 2) You need decent ACLs that isn't just IP based.
         | 
         | 3a) You don't ability to directly connect to a site (just one
         | needs to be accessible)
         | 
         | 3b) You can't add 3rd site to relay traffic or punch holes in
         | NAT.
         | 
         | 4) You're afraid of terminals and/or text editors.
         | 
         | Here is a good write-up on the subject:
         | https://www.procustodibus.com/blog/2021/11/wireguard-nftable...
        
         | jabroni_salad wrote:
         | > no other ISP
         | 
         | I live in Iowa and we partner with a fixed wireless provider to
         | get decent fixed wireless service to clients in places that
         | don't have anything decent. They lease space on top of
         | basically every tall structure in the region (grain elevators)
         | and agriculture is their main line of business.
         | 
         | We are specifically using them for private backhaul, but they
         | do normal internet access too.
        
       | cyrnel wrote:
       | > We all know how well IPv6 adoption has gone
       | 
       | What frustrates me is that people keep building solutions like
       | this that heavily rely on IPv4, even when forward-compatible
       | options exist. With clever use of IPv6 transition technologies,
       | you could have retained support for legacy devices while
       | generally using IPv6 everywhere else.
        
         | sgjohnson wrote:
         | Tailscale supports IPv6. But their IPv6 support is useless to
         | you if your ISP doesn't support IPv6.
         | 
         | This is a needed feature if you have no IPv6 AND are stuck in
         | CGNAT hell.
         | 
         | And I'm an IPv6 evangelist.
        
           | H8crilA wrote:
           | No, Tailscale creates both IPv4 and IPv6 connectivity over ..
           | well pretty much anything. If there's IPv4 - it will use it,
           | if there's IPv6 - it will use it. If there's some traversable
           | NAT - it will use it. I think we should dig out the old meme
           | about ADSL running over a pair of wet strings.
        
           | cyrnel wrote:
           | If you have an agent installed on every node that can already
           | traverse NAT, you don't have to care about what your ISP
           | supports.
           | 
           | There are many more IPv6-centric solutions to their problem.
           | Sounds like they didn't even try to think of alternatives and
           | instead reached straight for NAT. That wasn't necessary, at
           | least from the amount of information we can glean from this
           | one post.
        
       | timenova wrote:
       | I'm glad they released this feature. There are databases/services
       | which require you to input the IP address to listen on instead of
       | the network interface. This will greatly simplify configuring
       | those services.
        
       | jedberg wrote:
       | What is the advantage of using the CGNAT range instead of 10/8?
        
         | chrisfosterelli wrote:
         | That'd probably have a lot of conflicts with people's LANs.
        
         | rollcat wrote:
         | You're much more likely to be already using 10/8 as a part of
         | your setup, whereas 100.64/10 has only really been a thing for
         | residential/mobile ISPs. (I have no idea what happens to
         | Tailscale when your carrier gives you a 100.64/10.)
        
       | BonoboIO wrote:
       | Next thing: Vanity 100.xxx.xxx.xxx IP addresses.
        
       ___________________________________________________________________
       (page generated 2023-12-07 23:00 UTC)