> 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 rul

> 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.