4 ms·

In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whateve

In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic. Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that. but aren't we nitpicking a little here? veering on the "technically correct, worst kind of correct".

cesarb 2y ago
> In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic. Yes, but that's because it's co-located with a stateful firewall, sharing the same connection tracking state. Without that firewall, if a device on the WAN side sends to your router a packet with destination address on the LAN side, your router will route that packet to the LAN, even though it's not a reply to anything sent from the LAN to the WAN. That is: it's a misconception that port mapping NAT blocks incoming connections; port mapping NAT only affects outgoing connections and replies to them.
- cyberax 2y ago
  > if a device on the WAN side sends to your router a packet with destination address on the LAN side This can happen only if the device is directly attached to the NAT server. Basically, only your ISP can do that. Most NAT servers by default also prohibit this kind of routing (because why even allow it?!?), but even the most misconfigured bad NAT server is still vulnerable only if you control the ISP, in practice.
cyberax 2y ago
> Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that. But it is. Even a "full" firewall can't do anything against something on one of the inner host leaking into the outside. Most of the traffic is encrypted, even DNS. So the firewall can't operate on much more than the destination address to decide if a connection should be allowed. If you want more security, you need to secure individual endpoints.

cesarb 2y ago

> In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic. Yes, but that's because it's co-located with a stateful firewall, sharing the same connection tracking state. Without that firewall, if a device on the WAN side sends to your router a packet with destination address on the LAN side, your router will route that packet to the LAN, even though it's not a reply to anything sent from the LAN to the WAN. That is: it's a misconception that port mapping NAT blocks incoming connections; port mapping NAT only affects outgoing connections and replies to them.

cyberax 2y ago
> if a device on the WAN side sends to your router a packet with destination address on the LAN side This can happen only if the device is directly attached to the NAT server. Basically, only your ISP can do that. Most NAT servers by default also prohibit this kind of routing (because why even allow it?!?), but even the most misconfigured bad NAT server is still vulnerable only if you control the ISP, in practice.

cyberax 2y ago

> Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that. But it is. Even a "full" firewall can't do anything against something on one of the inner host leaking into the outside. Most of the traffic is encrypted, even DNS. So the firewall can't operate on much more than the destination address to decide if a connection should be allowed. If you want more security, you need to secure individual endpoints.