[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)
 
web link (tailscale.com)
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)