[Rapzid]

SNAT absolutely has intrinsic features that are utilized for security purposes.

This isn't to disagree with your main point. Many people in this topic have an oddly narrow definition "firewall" that tends to fall along the lines of "whatever makes me right and you wrong".

A statefull SNAT implementation itself has most of the characteristics of a "firewall".

[da_chicken]

> SNAT absolutely has intrinsic features that are utilized for security purposes.

Yes, but those features aren't there because they're security features. They're incidental to how NAT functions. It's not inherently secure. The intention of the design is to permit hosts on a network that is not Internet-routable to be able to send traffic that is Internet-routable. That's not a security feature. That's allowing traffic to pass that would ordinarily get black-holed.

> A statefull SNAT implementation itself has most of the characteristics of a "firewall".

Sure, but you should recognize that that's the same as saying a stateful SNAT implementation is an incomplete stateful firewall.

If your goal is to use private addresses, you should use NAT. The point is that if your goal is security, then you should configure a firewall.

Don't expect software that isn't designed to provide you security to provide you with any security.

[Rapzid]

SNAT is often a feature built on a network stack that also provides other "firewall" functionalities like filtering packets. Configuring SNAT is configuring a firewall? Or is only dropping packets a firewall? Or does the device need "firewall" printed on it? Does a device that has "firewall" printed on it still count as a firewall if it's not configured to filter packets? What type of filtering makes it a firewall? If an SNAT implementation drops packets is it a firewall? Is a linux/windows/bsd box with multiple interfaces a firewall? What if I slap "firewall" label on the box; a firewall now?

SNAT can be used to mask source IP and that can absolutely be utilized strategically as a layer of "security".

[immibis]

If your ISP delivered you a packet with a destination address of 192.168.0.5, there's a good chance your router would deliver it to that device without consulting the port forwarding table. In this way, NAT isn't a firewall and you're relying on your ISP's routing policy as your actual firewall.

[Rapzid]

If my ISP sent me a billion dollars I would be a billionaire.

What's represents a "good chance" the router is so grossly misconfigured as to allow inbound traffic no destined for the IP assigned to the WAN interface to be routed to one of the internal interfaces? I wouldn't be surprised, but what's a "good chance"? Is there data on this?

A typical, correctly configured SNAT implementation would most likely have the characteristics commonly attributed to a "firewall". An incorrectly configured network device may not have the characteristics commonly attributed to a "firewall", regardless of its ability to actually inspect and drop packets(which just about every commonly used OS network stack can do out of the box).

But even an SNAT implementation without typical "firewall" characteristics has intrinsic characteristics related to security; such as source IP masking. Which doesn't even need to be private.