Nope. Even with a misconfigured box that forwards the traffic from WAN to LAN, you need to be in the direct contact with the NAT server (an OpenWRT box). And that's the point, you are _not_, as is pretty much everybody else in the world, outside of people who have keys to my house and my ISP.
In practice, this provides all the practical security you need from a firewall.
> I'm just not in a position to take advantage of that, due to your use of RFC1918 addresses on the LAN side.
Well, duh. That's the whole point of NAT (when used typically). You don't get to access my internal network, you simply can't do that physically.
All you need to be able to do is send a packet that ends up at your router with the dest IP set to one of your LAN machines. This only requires being directly attached to your router if you're using RFC1918 on the LAN; if you're using a properly routed prefix then it can be done from anywhere.
> Even with a misconfigured box that forwards the traffic from WAN to LAN
Forwarding traffic from WAN to LAN isn't a misconfiguration. Your router needs to do that for TCP to work, or get replies to outbound UDP.
Or control the internal network of my ISP.
> All you need to be able to do is send a packet that ends up at your router with the dest IP set to one of your LAN machines.
Which you can't do.
> if you're using a properly routed prefix then it can be done from anywhere.
If I had a publically routed /24, then I wouldn't be using NAT in the first place. Which is the case in point: NAT _is_ a firewall.
> Forwarding traffic from WAN to LAN isn't a misconfiguration
Sigh. I mean allowing the SYN packets to be forwarded from WAN to LAN.
Whether or not someone can get that packet to your router in the first place is a separate question. If you're using RFC1918 then yeah, they'd need access to your direct upstream network. But the point I've been trying to make is that NAT doesn't influence the answer to this question: whether or not you do NAT has no influence on the behavior of any of the routers upstream of you.
NAT has no influence on whether these packets can reach your router or not, or on whether your router will forward them if they do arrive. That's why it's not a firewall: because it's not actually doing any firewalling.
> If I had a publically routed /24, then I wouldn't be using NAT in the first place. Which is the case in point: NAT _is_ a firewall.
It's not possible to go from "I wouldn't be using NAT if I had a routed /24" to "NAT's a firewall".
If you had a routed /24 then you might not use NAT, but that says nothing about whether NAT works as a firewall or not. The relevant part isn't "would I still be using NAT if the situation was different?", it's "does NAT block inbound packets?". Since it doesn't, it's not.
> Sigh. I mean allowing the SYN packets to be forwarded from WAN to LAN.
Well, yeah, allowing those is generally a misconfiguration... in the firewall. The routing part of the router doesn't pay any attention to TCP flags, just IP addresses.
When I set one up for you (back here: https://news.ycombinator.com/item?id=39173556) I gave you the access needed to actually do the test (...but you either missed that message or opted to ignore it, so you never tried it). You need to either move your network to routed IPs or give me a tunnel to the upstream network of your router first.
Not doing either of those doesn't make you right. NAT is still not acting as a firewall here. I'm just not in a position to take advantage of that, due to your use of RFC1918 addresses on the LAN side.