Comment by X-Istence | Hacker News Reader

Comment by X-Istence | Hacker News Reader

Parent Full thread

If send a packet destined for "10.10.10.11" to "71.28.10.10", your router would happily figure out "what interface do I forward 10.10.10.11 to" and it would happily send it to the connected device, because NAT is not a firewall. There is no rule stating that "packets destined for 10.10.10.11 on eth0 should not be forwarded to eth1". That's what a firewall is for.

And yes, your little router, is actually a router. It will dutifully take packets from one interface, look at it's routing table and figure where to spit it out. That's what it is supposed to do, NAT just adds a rule that says if a packet comes from eth1 and is destined for 0.0.0.0/0 (default route) out interface eth0 then we (the router) want to masquerade as if we are the source of that packet, so that this entire network looks as if it is coming from one single IP.

No firewall involved, and packets arriving on eth0 are going to get routed to eth1 all the same, since after all, we are a faithful little router.

This is how routing has worked since the dawn of time. Adding a firewall means we can say "but I should never see traffic destined to 10.10.10.0/24 on eth0, so drop it".

---

Either way, NAT may be part of the firewall but there is no requirement for it to be part of the firewall. When it comes to IPv6, just like IPv4, a firewall is required, and as soon as you have a firewall that blocks incoming traffic, then NAT becomes meaningless.

So if I'm understanding correctly, by spoofing the destination IP you can effectively manipulate the routing pathway and bypass the NAT to communicate with devices on the LAN?

There is no "spoofing" or "manipulation" or "bypassing", it's simply sending a packet to the address and a router doing what a router does, in a use case that simply doesn't involve the NAT.

The idea that NAT prevents inbound connections is simply a myth believed by tons of people who have no clue how IP works. It simply doesn't. So you don't need to do any "spoofing" or "manipulation" to "bypass" something that NAT simply doesn't do.

You might as well say that you can bypass a P.O. box by spoofing the destination address and thus effectively manipulating the snail mail routing. No, it's simply the case that you can address letters to street addresses and the postal service will deliver them to the address written on the envelope. Your mistake is in the completely baseless assumption that a P.O. box is supposed to prevent letters from being delivered to your street address.

Then why is it necessary to Port Forward / have an Open NAT in order to connect remotely in most cases such as online gaming or ssh?

That is PAT not NAT. Port numbers are a scarce resource and there are various ways to allocate them. This may be a 1:1 or 1:random or n:n static range or n:n random.

A stateful PAT would inspect packets to set up port translation and these things used to have lots of bugs and no filtering to check if the packet is from internal or external network at times.

You can often still send to the direct target port and IP if you guess or figure out the mapping. Scanning 64k numbers with packets is not that hard.

Because you can't route a packet addressed to 10.x.x.x or 192.168.x.x or other private network spaces directly over the Internet, which is the attack people are talking about here.

Because the internet generally does not route RFC1918 addresses, and in particular not to you. But that is not a security feature, as there is no guarantee that noone will ever send such packets to you, it's simply that those addresses are not (uniquely) allocated to you, and therefore, your ISP doesn't know to route them to you. Also, many ISPs won't accept routes for RFC1918 addresses from other ISPs because it is well-known that they are not allocated to any particular party, and anyone announcing them risks being flooded with packets leaking from local networks that cannot usefully be delivered anyhow.

But nothing prevents your ISP from sending you packets addressed to RFC1918 addresses. Or anyone who happens to have compromised your ISP('s router), for that matter. Also, it happens that ISPs fail to properly isolate customers, and neighbours who are customers of the same ISP can directly send layer 2 packets to your router. Or it happens that ISPs forget to disable routing protocols on customer-facing ports, and if your router is misconfigured as well, it might be announcing your RFC1918 prefix to your ISP, which then would start routing packets from its other customers addressed to that prefix to you (probably not from other ISPs, as BGP peers usually would drop such routes--but even that is not guaranteed).

It's just a convention to not route RFC1918 addresses over the public internet for the simple reason that they are well-known to not belong to anyone in particular, and in any case your ISP generally wouldn't know who of the many users of those addresses to deliver packets to. I guess that's a bit analogous to writing "to Joe by the big tree" on an envelope and dropping it in the mailbox. That is not a clear, unambiguous address, belonging to one particular person, so chances are the postal service won't know what to do with it and it won't ever arrive. But that doesn't mean there is a guarantee that it won't arrive. Some postal worker might happen to know Joe and that he is known in some circles as Joe by the big tree, and the letter might arrive after all.

If you get a packet addressed to 10.10.10.11 delivered to my home over the Internet then you kind of deserve to get in.

There will never be "no firewall involved" because NAT functionality is implemented as part of the firewall in the real world. Your point that it doesn't necessarily have to be part of the firewall is academic.

> There will never be "no firewall involved" because NAT functionality is implemented as part of the firewall in the real world.

So, you are telling me that, say, if you configure NAT on a Linux kernel, that necessarily implies some sort of firewall? (hint: it doesn't)

Hint: It does.

NAT is part of the netfilter module. Pull netfilter out of the kernel and you don't get NAT. It's even configured using the iptables command.

You can configure your firewall to do no filtering, but your packets are still going to be processed by the firewall module. You will still get automatic protections like reverse path filtering for example.

In practice when someone who doesn't know a damn thing about networking clicks the "do NAT" button on their router they're going to at least get basic protections like "No RFC 1918 destinations in on external interface" by default unless their vendor is pants on head. There's obviously more room to screw up if you're manually typing in iptables commands at a bash prompt, but at that point you should know better.

> Hint: It does.

So, if I configure NAT, that prevents inbound connections?

Or are you saying that it implies a firewall that won't filter a single packet, i.e., a firewall that is functionally equivalent to no firewall at all, but that you insist on calling a firewall because it makes you "win the argument" while not contributing anything useful to the discussion?

Yeah, and next I'll be selling cars with an air bag that isn't hooked up. I guarantee you, your head will be processed by an air bag module when you have an accident. So, who are you to claim that my cars don't have an airbag!

Reply on news.ycombinator.com