> which means it doesn't prohibit them

OK. I want to dig down into this. Let's say I have a router `R`, which I'm running NAT and optionally other iptables rules on. I've got a client machine `C` sitting in a private network "behind" `R`. `R` is connected to the internet via a gateway `G`. `A` is some machine out there owned by an attacker. There's a vulnerable TCP service running on `C` listening on *:1313.

       A
       |
    internet
       |
       G
       | 4.3.2.1
       |
       | eth_public 4.3.2.77
       R
       | eth_private 10.0.0.1
       |
       | 10.0.0.2
       C

`A` can't connect to 10.0.0.2:1313 since it's not routable from their position. Thus, the fact that NAT on its own doesn't prohibit traffic to `C` doesn't matter in this scenario, practically `A` still can't reach it. So far so good?

The only issue I can see is that if `A` can hack `G`, because `G` doesn't have to depend on routing to reach `R`, it can send traffic to `R` with a target address of 10.0.0.2, which `R` then forwards to `C`. I haven't verified that this works (don't have enough devices with me). Is this what you're after? Fair point.

If I'd add the following rule to `G`, `C` would be safe even if `G` is hacked[*]:

   iptables -A FORWARD -i eth_public -d 10.0.0.0/16 -j REJECT

[*] Of course that requires that any outgoing connections that `C` makes are not vulnerable against the possible packet manipulation from `G`.

Am I missing anything?

Edit: simplified the rule

PS. I'd welcome a good pointer (book or other) on network security and also IPv6; I'm a software developer, and only occasionally dealing with networks.