Internet centralization and the original sin of NAT
dreamstation.systems
dreamstation.systems
I implemented the current NAT system in Linux. In particular, avoiding port reservation in favor of squishing more connections into one IP address, as long as the remote address allowed us to differentiate.
This, in turn, means incoming traffic from a different address is unroutable. You no longer have a public endpoint. This is "poor man's firewall", but erodes our ability to have a server the way we used to.
I was a young engineer solving a specific problem, without considering the larger picture. It wasn't the only thing, but I feel it definitely moved the internet to a client/server infrastructure and a key equality was lost.
IPv4 without NAT was fucked at the design stage. To be fair: Who knew?
I was asked by my employer a while back to investigate this new www thing that has hit the internet (in around 1994 or 5, it took a while to notice) and I said it was a bit crap and no better than WAIS and GOPHER. I was using telnet on a Windows 3.1 PC and telnetting madly via a VAX and a X.25 PAD and what I now know was close to magic!
No one had any idea how things would turn out back then.
I'm actually quite impressed how long IPv4 has managed to work and without NAT (which I do mildly despise, given 30 years messing with this stuff), it would be stuffed.
Thank you for your work.
I had a corporate internship in the late 1990s and they blocked external web access.
They did, however, allow external Telnet access. This meant that whenever I had free time and/or was waiting for new projects, I would telnet back to my college server and use lynx to go read my favorite websites.
The Internet Protocol only concerns itself with IP addresses. The idea is that each computer has an IP address, so computers can communicate by sending IP packets; each IP packet says, "Message from computer with IP address X to computer with IP address Y".
But computers have multiple processes, so there's a need to know which process at the receiving computer is the recipient and which process on the sending computer is the sender. This is why transport protocols (TCP and UDP) add a port field. A port uniquely identifies a particular socket opened by a particular process on a computer. So a TCP or UDP message sent via the Internet Protocol contains the information, "From the socket with port 41590 on the computer with IP address X, to the socket with port 443 on the computer with IP address Y".
NAT is a giant hack which is primarily implemented in routers. It makes a whole household (or office building, or university campus) look to the outside world like one big computer with one IP address.
Say we have a computer with IP address L, a router with public IP address X, and a public server with IP address Y. The computer will send a message to the router which says, "From port 41590 @ L, to port 443 @ Y". The router will invent a new random port number (say 41200), add an entry to its NAT table which says "port 41200 means port 41590 @ L", then send a message to the public Internet: "From port 41200 @ X to port 443 @ Y".
When someone then sends back a message "to port 41200 @ X", the router looks that up in its NAT table and rewrites the packet to say "to port 41590 @ L", then sends it to the computer with that local IP address.
The computer doesn't really know that it's speaking through a router. It needs to know that "packets to the public Internet should be sent via the router" but that's it, the packets it sends and receives looks the same as if the router wasn't there. The rest of the world doesn't know that it's speaking to the computer behind the router; from their perspective, it looks like they're just speaking directly to the router. All the special network address translation logic lives only within the router.
Already back then, you couldn't easily deploy solutions which required all computers and middle-boxes on the Internet to change. That's why NAT exists in the first place.
You could deploy a new NAT implementation, but the problem NAT solves is fundamentally that there aren't enough IPv4 addresses for every computer to have an IPv4 address so you need multiple computers to share. I don't think there's a better solution to that problem other than switching everything over to IPv6 (which has been in progress for the past 30 years and has barely reached 50%).
As an aside, you see the term "CGNAT" sometimes as well. This stands for Carrier-Grade NAT and is an evolution of the NAT concept to much bigger contexts; a whole city could share a handful of public IP addresses, making large regions effectively one "local network" behind a "router". Multiple streets could look to the outside world like they're just one gigantic computer. Each household in that area will then probably do its own layer of NAT, making it look to the CGNAT router like the household is one big one computer. This configuration can be called "double NAT". Since each router doing NAT only needs to know about its own NAT, there's really no limit to how deeply you can nest it.
A lot of this feels like a requiem for the days when the only people on the Internet were "high-computer-skill" type folks. Most people will gravitate to "user-friendly" solutions: Gmail and other managed email providers were popular because they didn't stop working when you shut down your computer to save electricity, when your server's hard drive crashed, when you upgraded your computer to something with a faster processor, more RAM, and a newer operating system. It was hard enough to educate laypeople about URLs and email addresses (AOL keywords, anyone?), let alone a combination of random numbers in an IP address, or convincing people to register domain names.
Yes, NAT shoved fences into a network that was all about connecting everybody. But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning. ISPs would have just sold highly restrictive firewalls as part of their home-install basic boxes, and we'd still have ended up with those fences.
The thing about smartphones is that they are both completely dependent on wireless connections to central servers in order to function and completely unsuitable to operate as servers. If you forced your phone to serve files anyway, your battery would drain quickly and the CPU would be drowning in its own waste heat. You might argue that you could still do non-server things on the phone, but practically speaking, a node that can't handle server tasks is just a leech. P2P networks work on a mutual aid basis; they require the majority of nodes be capable of shouldering traffic or sharing files in order to be a net benefit. If you add, say, tens of millions of new mobile phones to the network, the network will become unusable as any desktop machine gets DDoSed by hordes of phones asking for a babysitter.
So even in the world where IPv6 did to v4 what v4 did to NCP, we'd still ultimately end up with "my files go in the cloud", because clouds are coinventions of smartphones, in the same way that cars are coinventions of suburbs. You can't have one without the other, and once you do have both, they become so economically dominant that others get socially coerced into using them.
Obviously it's all very basic, but with a few years of development and polish (and probably someone besides Nokia copying the idea) I think this would be a compelling product. You could basically have the same feature set as something like iCloud but without the subscription or your files going elsewhere.
Skype was originally peer-to-peer for comms, but ended up with "super-nodes" because of NAT limitations (not sure if STUN/TURN/ICE had been invented by that point). BitTorrent is still peer-to-peer. A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.
But this doesn't only hurt server-y stuff: you may not notice it if you're with a legacy MegaISP with lots of money to throw at IPv4 allocations, but if you're with a younger or smaller ISP, then there's a good chance you're behind CG-NAT, so many console games won't work.
All practical solutions for p2p these days require NAT hole punching through STUN and signaling servers anyway, so even p2p has to be bootstrapped via client/server. Easier to just keep the protocol client/server then.
I have been told in many HN discussions that IPv4 is good enough and that IPv6 doesn't solve any problems. ¯\_(ツ)_/¯
The problem is, and has always been, that NAT doesn't solve the IPv4 exhaustion problem. It took a long time before I understood this due to all the noise IPv6 people make, but newer ISPs don't have enough IPv4 addresses to give every household its own address, so they use CGNAT for residential Internet access. This is what people should be focusing on, but it's not. All arguments for IPv6 are irrelevant drivel about how bad NAT is.
The length of Tailscale's 2020 weblog post "How NAT traversal works":
* https://tailscale.com/blog/how-nat-traversal-works
and their 2025 "NAT traversal, and how we're improving it (pt. 1)"
* https://tailscale.com/blog/nat-traversal-improvements-pt-1
indicates the opposite to me.
Certainly there are still (SPI) firewalls with IPv6, but at least with CPEs things are limited to 'only' hole punching with PCP (or UPnP) as opposed to all the ICE/TURN/STUN layers (and heaven help you if you're behind CG-NAT).
> The problem is, and has always been, that NAT doesn't solve the IPv4 exhaustion problem.
NAT was intended to be a "short-term solution" as noted in the NAT RFC (from 1994):
This is such a common and stupid problem. It's the same with SSH; if you want to run your own git host, you need to either reserve public port 22 to git, or use it on a non-default port.
More protocols should have some kind of header to tell the server what name was used to connect, just like HTTP's Host header. If SSH clients told the server, "hey I connected via git.example.org", you could have an SSH proxy behind the NAT forward that connection to your git host. If the Minecraft client told the server, "hey I connected via survival.example.org" or "hey I connected via creative.example.org", you could have a Minecraft proxy server route the traffic to the right local address/port.
(I'm actually implementing multiplayer in a game right now and I'm adding this information to the initial connection handshake message, with the intention that you could make a proxy server.)
FWIW I (writer of blog post) am 21 years old and just a bitch lol
Also, the lazy sysadmin forgot to set a quote for today.
This works, until you have more than one person accessing your server. Then you need to worry about accounts, credentials, data isolation, etc. And then if a couple of people connect to your server and start using it, you have to worry about staying online, staying updated, backing up the data. But other than that... yes, trivial.
And just to be really explicit, you always have more than one person accessing your server, and most of the time they are unwanted users trying to break in.
Exactly. Of all the reasons why the average person doesn't have an Internet-visible server, NAT, I would say, is pretty far down on the list.
Exactly. Which is the issue with saying, as the article does, that NAT is the reason most people don't have an Internet visible server, when the real reason is that their computers need to be behind a firewall and once you're behind a firewall, safely opening up just little pieces of it for an Internet visible server is something most people aren't going to want to deal with.
In fact you could have an IPv6 address for each user, and if one starts becoming troublesome both revoke account and stop using that address.
You could create a new IPv6 address every millisecond, and it'd take 584,868,233 years to exhaust a IPv6 subnet (/64).
But an ordinary person? I don't see it. If it's tough for an ordinary person to handle safely opening a port in their firewall for forwarding, it's tough squared (or perhaps cubed or an even higher power) for an ordinary person to handle auto-creating a separate IPV6 address for every other person that wants to communicate over the Internet with them.
Not to mention, how does this work with DNS? If Ordinary Person wants to put an article up for others to read, how do the others find it? Surely not by Ordinary Person sending individually crafted IPV6 addresses to anyone who wants to read their article. (And how do they even find those other people if they are also creating new IPV6 addresses for everyone else?)
Thankfully, we have wireguard now. It drops all packets by default. From the perspective of people who don't have the requisite cryptographic keys, it's like the computer is not even there to begin with.
I've always found it strange how people just put computers out there on the internet and just allow them to interact with total internet randoms. Why are we allowing our computers to talk to strangers? No wonder people are getting hacked.
Jill from Elbonia may be always be a threat, but this doesn't mean that Joe from Accounting is not a threat or cannot ever provide a vector for Jill. :)
If anything, NAT has saved millions of wildly insecure devices running unpatched old Windows versions from getting pwned the second they connect to the open internet.
Going to a model of "you don't get a public IP address, all traffic must go through servers other people host for you" is what finally kills the open Internet. It's okay enough for cell phones where it's a hack to work around TCP/IP's lack of roaming support, but it should be illegal to deploy as residential Internet.
The conceit behind NAT is that 99% of traffic over the router will be client-server and the last 1% can get away with separately negotiating with the router to get inbound traffic.
For example my ISP Xfinity by default will put your router in CGNAT space (and ipv6) but if you request port forwarding from a mobile app the upstream router will assign you a ipv4 address and it all works. NAT is considered fine because adding roadblocks to server hosting is a acceptable tradeoff.
The reason they i think they can be so flexible is that they likey have a ipv6 backbone to route to all the customers and ipv4 is not used for routing but as a extra service layered on top with packing the 48 bits of ipv4 and port inside a ipv6 address via MAP-T
If you try to use those port forwarding hacks, you force every single piece of software to deal with the fact that the IP address it sees for itself is not the IP address its peer sees for it. And you force every single protocol design to allow for that possibility. Add in UPNP, and now you have to implement a whole extra (badly designed) protocol in parallel with the actual application.
It's not trivial to even discover the address your peer is seeing; even now there's a huge diversity of nasty unreliable hacks for doing it.
HTTP isn't the world. In fact, HTTP becoming "the world" was another part of the problem.
I don't think NAT being a janky ad hoc firewall does anyone a service. It shields the devices enough to keep the developers oblivious about security, but not enough to stop them from connecting to arbitrary hosts. This perpetuates the humongous botnet ecosystem.
This is worse for everyone in so many ways:
1. Forwarding ports suddenly makes you insecure, because you already were.
2. You have to fuck with your router config to even do that, and risk breaking something else along the way. Nobody should have to bother, because port forwarding shouldn't exist in the first place.
3. Many ISPs make it difficult or impossible to configure your firewall, let alone reserve a static public IP.
4. It's an eternal problem that isolates itself from any true solution. Any actually good UPnP implementation would just be stuck behind your NAT and firewall.
The entire premise "as long as you can control it" is the core issue, and the fundamental reason why NAT is the original sin. Without NAT, there wouldn't be anything to get control of.
In an alternate universe (or a current one with IPv6) every home router would have a default deny inbound security policy, and home admins could punch holes as needed the way they do today with port forwarding.
Its definitely the opposite. People started ignoring security because its "natted" anyways, even though NAT was never supposed to be security-critical. Thats what firewalls are for.
I sent them a screenshot of her shared drive through ICQ, and not long after she bought a router.
Software was created with no security because no one demanded it because no one cared. Technologies that came later did not create that situation.
You can have a stateful firewall that blocks non-established-connection packs and all your publicly addressable devices would not be reachable. NAT ≠ firewall (though they often glommed together on CPEs).
And NAT is also giving a false sense of security in some ways: "this device has an RFC 1918 address so is not reachable, and therefore safe". Yeah, except if another device already on the inside is / gets compromised. Perhaps if everything had a public address folks would be more circumspect.
Right, but it's easy to get in the mindset that because devices are on the "inside" network they are safer. This is the risk that NAT brings: RFC 1918 = safe(r).
If every device has a 200::/3 address, then even if there's a SPI firewall which prevents external connections, it may help to reduce this inside/outside thinking.
Just as an example, any device on your home network could have a web interface which you could access from anywhere using a web browser. All the smart light bulbs and things which need some stupid account on some service could be made so they're controlled by the user instead of some company.
I've set up things like this on my home network but it's a pain because I need to deal with port forwarding, and if I have more than one device I need to use a reverse proxy.
I doubt it.
Very few devices do port NAT without also doing firewalling, since firewalling is simpler.
This might not be a good thing. Perhaps if there had been no protection for those odious operating systems, they'd have died the horrible deaths they earned decades ago. We should only want to protect things we intend to keep, after all, and none of us wanted to keep that garbage.
I know of zero systems that can survive exposure to the raw Internet, unpatched and without administrative oversight, with uptimes of years.
Sure. And as long as nothing has to survive exposure to the raw Internet, no one will build anything that could survive it. Not sure why that's so difficult to understand. You seem to think that the protection is the reaction to dangerous operating systems, when it's the cause.
Doesn't mean much when you have a buffer overflow in kernel.
Eventually, we'll all be running Operating Systems designed on microkernels, which have been written by actual software engineers, and proven correct with formal methods.
Until then, we're going to suffer through endless series of increasingly severe cybersecurity incidents.
Computer Security is a solved problem, has been since the mid 1980s, secure proven microkernels, with almost all code in user space, capabilities based security, etc. have been just waiting to move into mainstream use.
We can end this nightmare.
[1] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
There isn't such a thing as you describe. There isn't a trend toward such a thing as you describe. What there is, is Windows 11, and Linux, and OSX. And when people complain that Windows 11 stinks, they're mostly complaining about the UI and the ads, not about the security or the lack of formal methods or the lack of a microkernel.
The closest there is to what you're describing is SELinux. It's still a monolithic kernel. (Though I think it did use formal methods, but I'm not sure of that.) The only microkernel candidate that I know of is the Hurd, and it isn't what we're all running, and shows no sign of becoming so.
IPv6 just works. DNS gives me the address and that's it, I am now talking to my remote computer.
In the "real world", you don't really need that much security. Your actual security comes from the fact that all the worst criminals are already locked up, most of the would-be criminals are afraid of being locked up, and if somebody does actually commit a crime, they will get locked up and won't be able to do it again for a good while. A lot of real-world security is about post-factum detection (think alarms, CCTV, panic buttons etc), because in the real world, detection and prevention are two sides of the same coin.
This only works because if a real-world crime happens, the criminal by definition is in the same location as the victim, and law enforcement cares most about the community they serve. If the criminal is across the world, as is the case in cyberspace, even if it's a friendly country, it's often "not their problem". This means internet systems need actual security, and NAT provides exactly that.
If not for NAT, we'd all need a firewall, and things would be almost if not exactly the same. In the real world, "leave things relatively open, because locks are mostly for keeping honest people honest" is a valid strategy. This strategy doesn't work on the internet.
You still need a firewall regardless of NAT. Otherwise, every time you take your computer outside of your home, you're no longer protected. Any attacker or compromised device on your hotel, airport, or coffee shop wifi network would have direct access to your machine.
There's probably a field of study with vocabulary and accompanying proofs of significant rigor that prove or disprove this. Maybe they'll stop by our little subthread and clear it up.
A NAT implementation could broadcast any "WAN" side incoming packets to all link local clients (aka: put everyone in the DMZ). The only thing preventing that is a stateful firewall.
This is a very common misunderstanding. NAT and firewalls are separate concepts. You can also have NAT with no meaningful firewall -- a port remapping NAT that allows anything through.
Most IPv6 networks are firewalled but there's no NAT.
You could share things easily, sure, but anyone could get hacked pretty easily and very targetted.
After NAT, sharing was still easy lots of 'piracy' apps, various messengers with NAT passthrough
Both before and after you needed to be technical, you can't ask someone that doesnt know about computers to set up an FTP server, and if they did it would be a nightmare and they'd likely share their whole drive
Same goes for anything else.
Anyway, we'll get the whole non-nat with IPv6, let's see what that brings
I would invest in a proper firewall for the entire home before opening up anything to the world, IPv6 or not.
Correct. Every home wifi router worth its salt will firewall incoming connections by default, whether v4 or v6. It's then possible (unless it's some shitty ISP-provided locked down device) to add specific allow rules, or allow all for a particular client.
egress is typically wide open, although sometimes they lock down particular protocols by default (eg. smtp, bittorrent)
That's mostly because a phone is very locked down, can you run an accessible ftp server on your phone?
It's also not windows
If you want to use the standard port, that's only true as of very recently, though, see https://issuetracker.google.com/issues/218578943#comment17
I'll believe it when I see it. So far it doesn't look like IPv6 will win anytime soon.
Ultimately I think none of this will be solved at the low level, it needs something like Iroh or libp2p where you build a new network on top of the Internet infrastructure, so that you can have things like persistent cryptographic identities and addresses that you can carry with you, largely independent of the underlying network architecture.
At home it can be if I connect t to my ip6 ssid, but there’s a stateful firewall which may as well nat.
Well, good to know!
I don't see a reason why my machine addresses should change over time... then again, most shouldn't have direct internet access anyway, a http proxy on firewall should be enough.
You can still use fixed addresses locally if you want, its not like IPv6 is forcing you to use the prefix assigned if you just want to communicate locally over never-changing addresses.
You can have your computers be fd01::1, fd01::2, fd01::3, etc, and talk to everything on their local addresses when wanting to stay local. And then when they want to talk on the public internet they can just use whatever public addresses like 2600:1700:53c2:2573:4c:c001:dead:beef based on whatever prefix your ISP gives you.
Its not like your devices have to only have a single IP address.
(I don’t personally run my network as ULA-only, I do ULA+GUA as you describe, but I had to basically give up on being able to reliably tie traffic logs to a known source… hosts in my LAN always seem to use a GUA to talk to each other when discovering over mDNS, which of course means they use privacy addresses by default. My ULA uses DHCP so that I can get stable addresses and know who is who, but it’s useless when things just decide to use the GUA anyway.)
In the US, it’s currently over 60%: <https://stats.labs.apnic.net/ipv6/US>
You can have firewalls with no NAT just fine. You can also have NAT with no firewall.
NAT is not about security and never was. It's about stretching the IPv4 supply and allowing each endpoint to just get one precious V4 IP.
Because of NAT, hierarchy (centralized servers) is the foundational design pattern of the internet, and anyone who wants any semblance of anarchy (decentralized networks) must use a workaround that is itself hierarchical and costly. We are all interconnected, but only a wealthy few can truly speak fist.
The issue that ipv4 exhausting and "solutions" around it like NAT are making it very hard for actual users (bussiness, people etc) to get access to public IP space without strings attached.
IPv6 solves a lot of this, especially because IP space is so massive LIR's don't need to be so spare with giving out address space.
The far larger issue we have is that applications are ingrained in a client server mindset, in which big incumbents want to have this architecture because it forces control from the server towards to client. And control usually also means having the data itself, which is where the real value lies.
The sin here is the hierarchy imposed by SSL and its infatuation with server names. Its says: these people are lords, they can wear the server hat. As for the peasants, your client hats are over there. If we catch a peasant wearing a server hat, the browsers will make them look like a criminal.
Our applications have evolved accordingly.
The idea of router sounds simple and like it should implement some standard protocols. But in practice -- a lot of it is a mishmash of proprietary, ad hoc shitware. Something I never hear spoken about is the deep packet inspection filter component of the router firmware. It's a part of the router that decides on what traffic is allowed / not, and almost no company publishes this part. So you're not even in control of your own Internet traffic, tiny blobs of code written by some company get to decide if something is allowed or not.
If that sounds sus AF and kind of a bad idea -- well, it is. You can always run 100% open software with open-wrt. But the thing is -- the Internet isn't just your part of it. It's a network of networks, and all those shitty routers, with all that shitty firmware, is deeply ingrained within the entire Internet. That's millions of devices that would need to be replaced to fix the issue.
I've never heard of a claim like this, so I'm really curious. Note that I'm not talking about the huge DPI market for corporate/state networks.
Absolutely not. They can charge your $9.99/mo so you can connect their craptastic app to their craptastic cloud so you can "use their app from anywhere".
If I wanted to blame large corporate "users" for NAT (which I actually do), I would blame their obnoxious intransigent refusal to upgrade to IPv6. That part wasn't the ISPs' idea, but it had nothing to do with the cost of address space and everything to do with shortighted laziness. They were, in fact, willing to pay for IPv4 space to avoid having to do anything.
Why do so many people still think NAT equals firewall when they're not directly related?
I guess it's because they're normally packaged together for practical reasons. They're both packet handling functions often performed in the same place. But they are NOT the same and you can have either one without the other. Most IPv6 networks have firewalls, and it's possible to have NAT that liberally passes anything.
I wonder how much this misconception has delayed V6 adoption? "But I'll be wide open without NAT!" No, you can have a firewall. Most IPv6 routers have stateful firewalls on by default.
The reason NAT is seen as security on home networks is that, absent a firewall, it acts as a default deny to inbound traffic.
It doesn't actually do that.
You don't need to take that on faith either -- you can just test it.
How do you want to go about doing this? Although, 100% of the time people have asked me to do this they chicken out at actually doing it, so I suppose you will too. You might prefer to test with some network namespaces instead.
http://github.com/richlegrand/bitbang-cli
I've been using it and it certainly has the potential. I signed up for Cloudflare's TURN server which you use with bitbang and it gets you 1TB free data transfer per month.
May be due to US DoD holding large amounts of IPv4 for no reason
https://news.ycombinator.com/item?id=49454785
> Even more ironic is that NAT got normalized as a security feature — “your devices are hidden!” — which is one of the things that made people resist the thing that would fix it.
That tracks. I briefly looked into the Tailscale website and I thought maybe I was wrong, maybe it's not a NAT/ddns toolchain, maybe it's something more complex that I'm too dumb to understand. But if my thesis that it's NATware is right, it makes sense to market it as a security product, it fooled me for one, but it also passes as a quality product for an organization, and they feel they are getting a security product when they are actually signing the purchase request of a developer that is applying networking techniques they learned from managing a videogame server.
I use it in 3 ways:
1. My phone connects to my home network by joining the tailnet. I can play music and movies from my home server when I am away. No struggles with configuration. 2. A dedicated mini pc at home is on a smart plug. I keep it powered off mostly. I can turn the plug on remotely and power the mini pc. It runs "tailscale --advertise-routes" which then exposes every device at my house to the tailnet. No open ports, but suddenly my phone thinks that it is back at home with all my home PCs. 3. I take my laptop with me and use "tailscale serve" which serves as a pipe. I can pipe my home movies to a smart TV at your house. Just install the jellyfin app, and browse for servers, and my server in my house appears in the list at your house.
Still not my cup of tea, but I think that the threshold of acceptable hacks is much higher for personal usage, there's no right or wrong, because it's as much a useful project as it is one of exploration and expression.
Thanks for sharing.
the first lets me provide locally hosted services without exposing them to the internet, by allowing members of the VPN ("tailnet" in their parlance) to connect to those services
the second was very handy to move a few users from a company in the process of shutting down to their homes, so they could continue to work like they had in the company network once the actual internal company network was shut down.
The other common but completely distinct usecase of VPNs being residential usage to encrypt traffic and even more distinct, with the purpose of masking the true origin of a request.
In the former type of usage, which is the one you use, I think any VPN system would fulfill your purposes, of course you have to use something, but I'd venture a guess that you are using the generic features of tailscale, not its commercially distinguishing features. But they are still very on brand, generic or not.
fwiw, the author/founder seems to have made a career out of building post-hoc hacks in one layer to fix the shortcoming of other layers, to take memcached as an example. I don't think my thesis is novel, that these types of hacks are subpar when compared to solving the issue at the appropriate layer, it's part of the tradeoff of the technologies, but I'm just particulary opposed to any hack that allows server admins to skip the step where they get a dedicated IP address, I'm less opposed (but still) to other types of hacks.
The main selling point is acting as a relatively efficient private overlay network, giving you a consistent private network even as devices move between different internet connections. (Something that NAT makes a bit harder but you don't get for free even if NAT isn't a factor)
But if I see a user that exposes a server without a dedicated IP address, and they use tailscale for this, the way I would describe it is that they are adding a third party node that routes traffic for them (just to provide multiplexing), so in terms of security, it's an additional unnecessary man in the middle. It's a testament to the marketing team that they are able to sell it as 'added security'. It's hard to know exactly how such open infra technologies are used, but I get the feeling that a good part of the customer base is buying tailscale to patch up a bad infra decision, while being (self) deluded into thinking that their system is very bleeding edge and secure.
Props to tailscale actually, lots to learn here, the lesson is to let the client save face and sell your tech not as something that fixes an embarassing mistake, but as something that's a bit opaque, high tech and implements security protocols, even if performatively.
Bonus points if there is upsell or onramp into actually sound technologies, like eventually you have to drop the whole tailscale thing and help the client actually get an IP address right? Or maybe even onboard the rogue ddnsed service onto the organization's existing ASN. It's a hard sell because the best solution in that case actually removes the product from the organization altogether, but I can imagine ways were the product stays in a non-central, QA-like sidechannel.
If you are listening on a public IP, you can trivially be attacked by anyone on the Internet.
If you listen on a private IP that only Tailscale can reach directly, you can only be attacked by Tailscale itself, or by anyone who successfully infiltrated Tailscale's network.
Should you run plaintext protocols over Tailscale? Absolutely not. But you're going to receive orders of magnitude less malicious traffic on a server accessible only over Tailscale compared to a server listening on the public Internet.
If you make your tailscale available to the internet through tailscale, you are still weak to external attackers, putting a VPN in the middle doesn't fundamentally change that dynamic, maybe it shifts it around and it confuses you enough to feel less shifty about it.
But it doesn't decrease your risk, if your HTTP server is weak to a tailscalething.tld/../../etc/ attack, it doesn't really matter that requests to other ports are blocked, (which probably don't even have processes listening anyways)
Not if it's a private server, like the poster above was describing. For example, if I want to maintain a NAS to store my photos and view them anytime, I am better off running it on a Tailscale network that only I (and some friends/family) can acces, no reason to expose it publicly and then try to secure it.
It just works: connect devices and they immediately show up in their portal. Most config is just clicking, but more advanced things can be configured as well. Definitely feels like a high quality product, not just something thrown together by a developer that learned a few network techniques.
Huh. Why are you doing this, is the datacenter IP being (rightfully) blocked by some service to avoid abuse? Is your usecase breaking some services ToS?
Certainly adding more fire to the "never a GOOD reason to use this" thesis
So you make up reasons to be judgemental and then insist they're right?
It's practical to block entire datacenters. It's not so "right" that working around it becomes "wrong". If whatever the server's doing can fit through a single home connection then it's probably fine.
I'll give you a concrete use case: A few times a month I want to wget a file on imgur to my server. That's a valid action miles away from any kind of abuse, but the IP range is blocked so I use my desktop to do it. If I routed it over tailscale instead that would be equally valid.
At that price point you can get a small vm, but if you have a dedicated server you want to use on-prem, 10$/mo seems like a reasonable price.
> Or I can use DHCP, where my IPv4 address can change at their whim.
Check the dhcp.lease to make sure, I used to think that, then I looked at the dhcp lease and the IP was being reserved for up to 48 hours of disconnection. I went years without it ever being released.
Phone operators won't necessarily transmit this information to you, the true ISP operator is the DHCP server. Not only is it more knowledgeable, but DHCPd has no incentive to upsell you, just provides you with what it is configured to.
I'd even go as far as checking if you can send parameters during the dhcp lease request, maybe you can request a longer lease on the IP.
There's a right way to do things, it's not trivial to discern from the wrong way to do it, but once you see it, you notice that you lose almost nothing, it's not like the 'wrong' way is simpler, it's just 'wronger', all the way through. I guess the reason they persist is sunk-cost fallacy, the businesses and people that went with NAT then developed STUN, and then they developed ICE, and then they develop Tailscale, every time you need to invent a bigger spade to dig you out of the hole and into a deeper one.
Or you can just use IPv4. But aghast, you have to pay 10$/month (or learn DHCP)
There's nothing to learn here in the end. Its just rules imposed by the ISP. I've had places where the leases expired weekly, and I'd often get a different public IP address when renewed. No amount of learning will change this. If I want out of that, I'd have to pay extra money every month.
I've also had ISPs where I've had the same IPv4 address for years. So long as I was online around the time of the lease renewal, I was pretty much guaranteed to get the same IP. YMMV.
> At that price point you can get a small vm, but if you have a dedicated server you want to use on-prem, 10$/mo seems like a reasonable price.
So I can spend $10/mo for each IP address I want, or I can just use IPv6 where my ISP gives me 295,147,905,179,352,825,856 IP addresses (a /60) by default for free. Hmm...which to choose...
In the end its still a bajillion-ish IPv6 addresses I have to play with versus the one-ish I have with IPv4.
On the other hand, it's not really that complicated. Cost seems to be around 10USD per month, which is what another user mentioned. And the GDP per capita of china is around 12000 USD per year, so it works out to a bit more than 1% of a salary, not sure if my maths are wrong, but from the perspective of a service provider, it still sounds like a sensible price point.
India has a lower GDP per capita, but I know that they make non profit collective efforts to massively lower prices.
Note also that a substantial part of the value and purpose of IP addresses comes from their cost. There is a PoW/PoS mechanism that associates some cost to some identity (similar to domain names), and this is part of the mechanism by which networks filter malicious traffic and defend against sybil attacks.
So 10$/month might be expensive, but it's probably the right price. If it were much cheaper than that, like 1$/month, or even 0.1$/month, abuse would rise, especially in China which, no offense, but doesn't seem to value the notions of civil law like contracts, Terms of Service or copyright dearly. At least they don't do it out of malice like Russia, it's just a difference of values, but it's probably for the better that IPv4 addresses are 10$/month, if it were 0.1$/month, I would probably just block the whole country.
Every. Single. Individual. End. User. Device. Should. Be. Addressable. Given that there are more such devices out there then there are IPv4 addresses to begin with, cost doesn't even come into it.
No, the question was taking the price that the NIC sells the IP blocks at. Understanding that in order to get 1 IPv4 address you will be buying from a distributor at a markup, but still, with Wholesale prices at 0.6$ (LACNIC) to 2.5$ (ARIN) per IP address per year, even with a markup of 300%, we are still at filthy cheap prices (2.4$/year to 10$/year)
>Every. Single. Individual. End. User. Device. Should. Be. Addressable. Given that there are more such devices out there then there are IPv4 addresses to begin with, cost doesn't even come into it.
Oh, ok, I was writing mostly about server side IPv4 assignment. I guess your position is a much stronger stance than mine, I argue that all servers should have an IP(v4) adress, you argue that every client device should. In that sense, consider that there's a lot of users, on this website even, that insist on running hosts without a dedicated IP address. There's lower hanging fruit.
In the IP world, there is no difference between an "client" and a "server". There are just two things communicating. Things which may be clients may also behave like servers from time to time and from circumstance to circumstance.
My home PC is sometimes a "client". Its a "client" when I'm talking to this website. Its also a "server" when I'm connecting to its file shares. Its also a "server" when I'm wanting to stream games from it. A game console is sometimes a "client" when its downloading games and updates, its also sometimes a "server" when I play games online and do matchmaking. My phone is a "client" when its talking to the messaging app servers, it is also a "peer" when I make a phone call to my friend.
Thinking that things are only ever "clients" or only ever "servers" is an overly simplistic view of the world. Devices aren't purely "servers" or "clients", applications/services are what make such a distinction, and even then that can change depending on the context.
There is one in the og tcp standard though. Server, listening, ports are well known, and they uhh listen. Might be semantical, but it's in the spec. Listening port is dedicated to an application type.
Furthermore the newer protocols like NAT make an even clearer technical distinction, clients can have no dedicated ipv4, but servers must retain that property. See? They are different in technical nature.
That's without even getting into empirical protocol semantics. Your device is not a server, it never opens permanent ports associated with a specific process for non-local connections. Nor does the router even do that by proxy, the natting router may provide a listening pseudoport, but it does so in an ephemeral per-connection fashion.
No. Both servers and clients can have no public ipv4
TCP isn't IP.
> Server, listening, ports are well known, and they uhh listen
Sure, but that's the application not the device. A device can have outbound connections and can be listening.
> clients can have no dedicated ipv4, but servers must retain that property. See?
My desktop at home has no public dedicated IPv4 (technically neither does my router, it's DHCP and subject to change), and yet still has listening ports.
If I've got httpd running on multiple things on my LAN which get IP addresses from DHCP, and I've got a reverse proxy that's getting NAT'd traffic from the router and proxying those requests, what is the "server" in this setup to you? These devices don't necessarily have dedicated RFC1918 IPv4 addresses, they're all just DHCP and register those IP addresses in the DNS which is referenced by the proxy. They'll change constantly for this example. (Note: this is extremely common in containerized or autoscaling deployments, not entirely a hypothetical!)
> Your device is not a server, it never opens permanent ports associated with a specific process for non-local connections
Sure it does. It's got dozens of ports permanently opened. That's my point. It's not like I have to go to the server store and buy a server to have ports open. I just launch a process and make a change to my device firewall, and now I'm a "server". The same device I'm using as a client to talk to you right now. Incredible! I can even use the same application, like a videogame, to be both a client and a server at the same time! I can start a match, join it at the same time, and allow outside players come join, and that might all technically be in the same executable!
> Nor does the router even do that by proxy, the natting router may provide a listening pseudoport, but it does so in an ephemeral per-connection fashion.
The router is just routing packets. It is not opening a listening port. It gets a packet delivered, it applies a set of rules to it, and passes it out an interface. If you think a router has to be "listening" on a specific port to receive that packet, you're misunderstanding what a router is doing. Sometimes you might even NAT without taking into account a port or a protocol at all!
Vendors have been pushing it though, because implementing IPV6 only somehow is still a very, very scary thing for large ISP's to pull off.
what should happen is it should be very easy to deploy ipv6/4 translation mechanisms in ipv4 only networks, this would allow easy interopability and make it easier for the large networks to push IPV6.
We have dozen of RFCs and vendors gears support IPv6 as well, but it just not finished
1) The typical "NAT" is a "PAT", which requires state for mapping traffic flow. An implementation is going to look very similar to a stateful firewall, by necessity, not accident.
2) The use of RFC-1918 addresses behind the router / NAT box provides some protection. If your address is not globally reachable, it's much harder to reach any hosts behind it. Yes, a poor implementation might allow direct routing from adjacent networks, like your ISP or neighbor. But that still isolates you from 99.99% of the internet.
I ran Linux, *BSD, and Solaris systems for years without any firewalls, host or otherwise.
Working around NAT was trivial for the people who actually cared about it. I was adding port forwarding rules to my parents' router at age 12. Turns out exposing a poorly-configured Windows XP box to the wider interwebs is a Really Bad Idea - and for the same reason UPnP letting random unpatched shady P2P applications do the same is Very Much Not Good.
Let's face it: consumer devices simply aren't secured well enough to let the entire internet poke around in them, and it was even worse a decade or two ago. Decentralization is pointless when it only results in people compromising their own machines, and the people with the skills to set up a 24/7 Linux server in a broom closet won't care about adding some NAT forwarding rules.
Even without NAT, we would've definitely gotten home internet routers firewalled with a default-deny policy on all incoming connections. Exactly the same "manually configure a bypass, or use UPnP" dance blocking you from trivially running a web-available service on your machine, but with a firewall rule rather than a NAT port forward.
It's of course a different story with CGNAT, but that only became a thing well after the internet was already centralized.
When I consider that quality of IPv6’s design, it communicates to me an old and ideal vision of what we thought the internet would and should be - a hyper-connected, shared infrastructure where [Layer 3] identity is universally unique such that connectivity between any two arbitrary nodes is possible (which obviously isn’t true for NAT w/ overload).
I’m just a lowly SysAdmin who finally decided to get his CCNA - so I’m a nobody - but as I worked through the material I felt like I was paging through a history book or biography of how the Internet’s life came to be and all the mistakes made along the way. Most features felt like patches for design considerations that were overlooked. Examples: DHCP Snooping, STP’s various * Guards, and the mere fact that Layer 2 and Layer 3 addresses are distinct concepts.
I don’t think there’s any disagreement that NAT was co-opted as a security feature. I never hear that said in a positive way, either. I think if we were to start over, with IPv6 as the default assumption, the tools we’d develop for network security would look very different, but not at all impossible or any more difficult.
But again - I’m a nobody. Just thinking out loud here.
So, of course, we then got Privacy Addresses, or whatever the name is. Which now means that you don't actually have a stable unique public IP, it actually changes all the time, and legitimate tracking and logging of your own network activity actually becomes much more complicated on IPv6.
If it weren't you couldn't have the same IP over several interfaces.
>mere fact that Layer 2 and Layer 3 addresses are distinct concepts.
The logical separation between the ideas allows for a lot of flexibility, and there were some wrong answers on how scalable vs flexible things should be.
Ethernet and IP beat the shit out of everything else: https://en.wikipedia.org/wiki/Protocol_Wars
They emerged with a decent answer: L2 crosses intranetwork, L3 crosses internetwork. Their separation allows L3 addressing to be completely unaware of multiple changing L2 (lower level) intranetwork switches, which is immensely useful.
Trying to solve everything with One Master Protocol to solve it all turned out like this: https://xkcd.com/927/
IPv6 solves this by doing neighbour discovery on link local addresses and multicast addresses.
I took a course called “Introduction to Internet Architecture” back in 2017 with a wonderful professor. The course opened with a prompt, “What is communication?” We started with smoke signals and worked our way up the OSI layers (including voltage-level encodings on the wire). I remember drawing those layers and asking, “What problem is each layer trying to solve?”
Also that XKCD comic is a classic. Love it. I don’t see any value in overhauling the protocols of today. It seems like the future (or present) of networking is overlays. When this recent cert covered SDN, it really abstracted away everything I had just learned and I felt a little sad about it honestly - as if switch/router configuration would some day be ubiquitously software-defined, getting totally buried by the application layer and becoming almost apocryphal like assembly or machine code… something we know exists but rarely touch.
This is the cost to splitting your routing between layer 3 and 4.
I'm now IPv6 everywhere, and so I get to just use ping. Much simpler.
Further, protecting IPv6 services is simpler, because I can terminate (m)TLS on the backend. With a reverse proxy on another host, I have to have yet another means of securing the proxy-backend path. Yet more complexity!
> And the fact that consumers can't just directly connect to each other is a feature.
Consumers should be protected by firewalls. That's independent of routing.
New network growth (mobile, Africa, Asia) uses it, old growth stays on v4 and will eventually roll over. People with address space usually don't need much more, but the IPv6 space better reflects how connected the world is - we're gonna need a bigger address space than v4, that's for sure.
New protocols shipped quickly on rough consensus and working code and weren't perfect - some left all kinds of undefined behavior, or lacked clear advantages over predecessors and competing protocols.