Comment by hvidgaard
12 years ago
NAT'ing is such an ingrained way of doing things, and it also happens to be a great way to separate your network from the rest of the network/internet. I don't think it'll go away any time soon.
12 years ago
NAT'ing is such an ingrained way of doing things, and it also happens to be a great way to separate your network from the rest of the network/internet. I don't think it'll go away any time soon.
Please allow me to be pedantic here. What actually separates your network from the rest of the Internet is called a firewall. It is unfortunate that common usage has conflated the two terms to the point that many people believe they must be inside a NAT to be firewalled from the outside. It's actually one of many misunderstandings related to the IPv6 transition.
I like to explain it to friends like this-
A Firewall is exactly the same thing as a bouncer at a club. The firewall-bouncer decides if you, the packet, get into the club. He might let you in, he might ignore you, he might tell you no.
NAT is a dinner party at a house on a block. There's no bouncer. If you know the right house, you walk right in the front door. But there sure are a lot of houses! So it seems unlikely that someone will crash your party, but don't you trust the bouncer more, now that you're thinking about it?
I'm not sure I follow your analogy. With a NAT configured to only forward certain ports to certain machines, the "bouncer" exists as much as in the firewall case. The question is not whether a NAT can be an effective firewall; it's that it brings some other, rather unsavory features along with it.
Don't get me wrong, I know the difference between NAT and a firewall, but NAT'ing automatically (and by definition) hides the network behind, firewall or not.
Then you are using NAT as a simple firewall. You could have the firewall part without the translation part (or with deterministic two-way translation), which would eliminate 99% of problems. let me explain:
A NAT "hides the network" behind it because it does two things:
1. drops incoming connections (or more precisely, incoming traffic when there was no outgoing traffic from that ip:port on that protocol)
2. obscures internal network addresses
Dropping incoming connections is what makes it a simple firewall and you could set up a "real" firewall to do the same (there are probably products doing that out of the box). Most firewalls are more complex than that, but they don't _have to be_.
What makes NATs different is the address translation that obscures the structure of the network behind it. Traditionally this is needed because you have lots of internal addresses and few external addresses (often just one). But if you have more hosts than external IPs then you can't have a static mapping without collisions because you have more internal ip:port pairs than external ip:port pairs. Which is why NAT generates internal-external mappings as it goes and why old mappings need to be discarded and why it needs to drop incoming connections (it can't know where to forwarded it to if there is no mapping). THIS is the part people hate, because it means you can't reliably connect two NATed hosts. If hole punching worked reliably it wouldn't be a problem, it feels like a hack, but the internet is a patchwork of much worse hacks.
1 reply →
I do believe you know the difference; your wording was clear enough. I just took the opportunity to dispel what seems to be a common misconception (not as common on HN, I hope!)
Most soho ipv6 routers (that also do v4 nat) do connection tracking for their v6 subnet, blocking inbound connection attempts by default, to emulate the security properties of v4 nat.
This means that you still have the same "unconnectable from the outside" problem you have with v4 + nat.
Yes, I too wish it weren't this way.
At least with a decent, non-greedy ISP you have the option of turning off said connection tracking and enjoy your fully routable /48. But I do understand how it remains a problem when most people don't know or want to do that.
Ideally, there could be some kind of uPnP-like protocol to open ports on an IPv6 middlebox, so that you can have a firewall on by default but still be able to punch a hole through it, without user intervention, when an application needs so.
Maybe there is; I haven't checked.
I actually think that's a sane default. With NAT it's a PITA to undo that and in some cases impossible (e.g. when you have 2 machines on a LAN using a protocol that requires a static port, so you can't just forward to a specific machine). With stateful firewalls, it should be much easier to just say "Allow port X through" and have a single application "just work"
NAT separates your network as much as buying 10.10.10.* and assigning 10.10.10.0-100 to the internal network.