> How can a rule that doesn't apply to inbound connections possibly do anything about the behavior of inbound connections?
Outside of exotic situations, part of setting up a NAT is putting your internal hosts on a private IP range. This makes inbound packets impossible (if your ISP didn't screw up).
Even if you didn't do that, all you have to clarify is that you're replacing the existing routing rules with NAT. Mystery solved.
Due to the extreme address shortage in v4, of course it's typical to be putting your internal hosts on a private IP range. But "putting your internal hosts on a private IP range" isn't NAT.
And in fact, putting your internal hosts on a private IP range doesn't prevent inbound connections either. It'll limit the set of people that can do them, but anybody on your immediate upstream connection can do it just by sending packets to your router. That probably means at least your ISP and anybody who can order them to cooperate.
NAT isn't a security boundary.
(And if you replace your routing rules with NAT then everything will break, because the only thing NAT does is rewrite addresses in packets. They still need to go through the routing table to be routed.)
> Due to the extreme address shortage in v4, of course it's typical to be putting your internal hosts on a private IP range. But "putting your internal hosts on a private IP range" isn't NAT.
Maybe not private, but I think it's fair to say that putting them on a different IP range is expected enough that you can reasonably call it part of NAT.
> They still need to go through the routing table to be routed.
You're looking at things from a very iptables-centric view.
"Accept packets on one network interface, rewrite them, spit out the other interface if the rewrite succeeded" is a valid description of NAT that replaces all other routing.
It also prevents the "ISP screwed up" and "malicious ISP" scenarios, if your NAT is port-based. It doesn't even care if you used different IP spaces or just one.
The choice of IP range for your network is still a conceptually separate thing from the choice of whether or not to NAT outbound connections from said network. Certain choices of IP range might make NAT more or less useful to you, and thus might influence your choice, but it's still a separate thing.
Yes, I'm describing behavior from the perspective of Linux and iptables because that's what I'm familiar with... but this is the generally-understood meaning of "NAT" when used in this context, and as far as I'm aware this is how basically everything implements it. This is the behavior you'll be seeing.
Nevermind the discussion of IP range for now, I didn't explain well enough and I don't want it being a distraction.
> this is the generally-understood meaning of "NAT"
If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right? I think that's a reasonable expectation, and it does not require any routing to do. And since the attack we're talking about depends on using routing to bypass the NAT, a dumb device that doesn't route is not vulnerable, and does not make your network vulnerable.
[I'm posting this as an attempt at general education. No personal attacks or hostility intended]
> If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right?
Only if they haven't read RFC 2883 (or similar documentation). I would describe a "device that does NAT but not routing" as highly unusual, possibly purpose-built to update an older network or workaround some kind of compatibility/interoperability problem. Such a device would probably be a custom iptables (or equiv) configuration on a standard linux (or equiv) box, not a branded "router".
However, another interpretation is that the terms "NAT" and "routing" are being used in the colloquial sense that usually only refers to NAT and routing to refer to something roughly similar to the home devices that sit between the LAN and a {cable,ADSL} modem. In that sense, a device with two cables attached might not appear to "routing" anything. In previous posts, I'm using the technical definition of NAT as defined by RFC 2883, not this broader colloquial definition.
By the technical definition, the device is "routing packets"! NAT is defined as something that performs "transparent routing" between address realms. From RFC 2883: [1]
2.2. Transparent routing
The term "transparent routing" is used throughout the document to
identify the routing functionality that a NAT device provides. This
is different from the routing functionality provided by a traditional
router device in that a traditional router routes packets within a
single address realm.
Transparent routing refers to routing a datagram between disparate
address realms, by modifying address contents in the IP header to be
valid in the address realm into which the datagram is routed.
NAT transparently[2] "routes" between address realms[3], which are defined as:
2.1. Address realm or realm
An address realm is a network domain in which the network addresses
are uniquely assigned to entities such that datagrams can be routed
to them. Routing protocols used within the network domain are
responsible for finding routes to entities given their network
addresses.
NAT accomplishes this "routing" between realms "by modifying address contents in the IP header". Changing the SRC Address field in the header is routing the packet! Any further routing decisions do not involve NAT. Once the packet's address has been changed, the actual handling of the packet is performed by the "routing protocols used within the network domain". This is also what happens to packets that were received directly into that network domain. A simple implementation might do something roughly similar to this (note: oversimplified):
| | /-----------\
| | / [Firewall] \
\ New Packet Received / | unroutable, |
\ From NIC / \ drop packet /
\-------------------/ \-----------/
| ^
v addr: unknown |
+----------------+ +-----------------+
| is DST addr in | Y | [Packet Router] |
| realm "WAN"? |--->| rules: "WAN" |
+----------------+ +-----------------+
N | addr: NAT |
v v
+----------------+ /--------------------------\
| is DST addr in | / "Route" from realm "WAN" \
| realm "LAN" | | to realm "LAN" by changing |
+----------------+ \ the IP header address /
N | | Y \--------------------------/
v | |
/-----------\ | v
/ [Firewall] \ | +---------------------------+
| Bad addr, | | | Hand off packet to be |
\ drop packet / | | routed into its new realm |
\-----------/ | +---------------------------+
v |
+-----------------+ /
| [Packet Router] |<--------------/
| rules: "LAN" |
+-----------------+
| To: the "LAN" firewall,
| other processing,
| maybe TX at the
v LAN's NIC
(...)
NAT simply hands the packet back to be routed to the LAN. Since NAT is defined as a "transparent" routing, a NAT-translated packet should be handled the same as any other packet addressed to the LAN.
> a dumb device that doesn't route is not vulnerable
If packets going into the device are retransmitted in any way, the device is "routing" packets. Dumb retransmitting/repeating packets ix a type of routing, even if it isn't making important decisions about each packet. Fortunately, most devices include a stateful firewall that DOES make important decisions about how to handle each individual packet.
> does not make your network vulnerable.
*If-and-only-if you had that unusual NAT-only, no-firewall device - which is very different from a typical home router - it could route packets to your private LAN if they were addressed to a valid LAN address (perhaps 192.168.1.x?). They would bypass NAT and be routed to the LAN, just like the router's own communication with the LAN. You wouldn't expect NAT to touch packets sent from the router's management HTTP server to a host on the internal/private LAN.
The malicious packet might be sent from something like a smart TV" that you "isolated" in a 2nd LAN or DMZ connected to the same router. Fortunately, most routers are not vulnerable.... because they include a firewall that drops "obviously invalid" packets.
[2] Transparent to the src and dst hosts that sent/received the packet. This "transparent" is referring to the hosts using the NATing router do not need to do anything special when sending/receiving packets. The address changes are invisible to the endpoints.
> If packets going into the device are retransmitted in any way, the device is "routing" packets. Dumb retransmitting/repeating packets ix a type of routing, even if it isn't making important decisions about each packet.
A hub is not a router. An inline repeater is not a router. That is not a normal or useful definition.
> flowchart
When most people talk about routing, I think they mean the boxes you labeled [Packet Router]. A NAT-only device would basically remove every conditional box, remove every box labeled [Firewall], and remove every box labeled [Packet Router].
Packet received -> Rewrite headers -> Packet output.
Technically you'd have two identical flowcharts, one for each direction.
> If-and-only-if you had that unusual NAT-only, no-firewall device - which is very different from a typical home router - it could route packets to your private LAN if they were addressed to a valid LAN address (perhaps 192.168.1.x?).
Any packet coming in from the internet would hit the rewrite engine, the rewrite would fail, and it would not make it to the LAN.
> They would bypass NAT and be routed to the LAN, just like the router's own communication with the LAN. You wouldn't expect NAT to touch packets sent from the router's management HTTP server to a host on the internal/private LAN.
If you had to have a web interface, then packets coming from the NAT device itself would be sent directly to the port, not to the NAT engine.
But for this thought experiment let's just not have a web interface.
> The malicious packet might be sent from something like a smart TV" that you "isolated" in a 2nd LAN or DMZ connected to the same router.
Packet from a LAN? It gets NAT applied and goes to the internet. The internet can decide what to do with a destination of 192.168.0.107
(I would have said you can't even have two LANs without routing, but you could force it to happen, like making every WAN->LAN packet go out to both of them.)
All these attacks you're listing are using routing to bypass the NAT functionality. Not possible in a device that cannot route.
> Changing the SRC Address field in the header is routing the packet!
That is an interesting and pretty convincing argument. Two caveats, though. One is that this is still a separate thing from "packet routing" or whatever you want to call picking a direction/vlan for a packet to go to based on routing tables.
The other caveat is that it might just be imprecise language. What if "by" means "by also". They are assuming you have a normal router as a base, are making it transparent by adding header modification. So then transparent routing is a combination of routing and header modification, but header modification all by itself is not routing.
Because the RFC assumes you started with a router, maybe I should say "just the Network Address Translation portion of the NAT RFC" instead of "NAT", but that seems like an unnecessary level of pedantry.
Outside of exotic situations, part of setting up a NAT is putting your internal hosts on a private IP range. This makes inbound packets impossible (if your ISP didn't screw up).
Even if you didn't do that, all you have to clarify is that you're replacing the existing routing rules with NAT. Mystery solved.