If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.
> If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.
This is generally going to be true, but it's not relevant to how NAT behaves when it receives inbound connections.
I recommend you setup a basic iptables NAT set of rules on linux to reflect what a home router does (masquerade) with ip forwarding enabled.
The inbound packets from the internet are to a public IP that belongs to the device performing NAT. If there is no entry in the conntrack table from a connection to translate that public IP to a private IP, there is nowhere it can be forwarded to. It’s already at the device that owns that destination IP.
Even if it spit the packet out a private interface (which makes no sense given the routing table), the destination IP would be a public IP that both cannot be ARPed for on the local network and will not be honored by any private device.
I think it's someone else's turn to do the test now.
> The inbound packets from the internet are to a public IP that belongs to the device performing NAT.
If the inbound packets are addressed to the router, they get delivered to the router. But you cannot just declare that that's where they'll be addressed. You aren't in control of what packets show up to your router, you're only in control of how you process them after they show up.
What you’re describing would happen if NAT were completely disabled. You’re just describing an open router
> What you’re describing would happen if NAT were completely disabled. You’re just describing an open router
Yep. It also happens when NAT is enabled. A router doing NAT is exactly the same thing as an open router -- it just has the additional property of editing outbound connections to appear to come from the IP of the router itself.
If NAT on its own blocked inbound connections, I would have seen that in my tests.