This question came really as a need to transition off “public” IPv4 space on an internal network and to the more commonly RFC1918 internal address along with NAT (for security reasons). This posting is the bulk of my reply to the customer. I really see this as the often-discussed question “Is NAT security?”. My wording/frame of reference here is as if I’m writing to someone not entirely familiar with NAT. I tried to provide some reference material below ; to avoid a pure appeal-to-authority. Okay, here goes:
0.) The introduction of NAT to networks was not done to provide a security benefit but to provide a reduction in the use of public IPv4 addresses. This was undertaken due to rapid depletion and exhaustion of those resources in the global internet. Organizations not facing those dilemmas do not face that need.
1.) NAT can provide some security benefits by ensuring the internal IP addresses are obfuscated from the external world. These benefits are eliminated if we don’t use NAT at the edge. While this is true in theory, most services provided to external sources utilize static NATs to ensure the IP address (and better, the dependent DNS entry) are fixed and consistent. This ensures the stateful packet filter at the source network will know to let the traffic out towards your network. As static NATs are fixed the benefit of obfuscating the internal IP address is moot – sending to the public IPv4 address will ALWAYS result in traffic reaching the internal IP anyway. The only preventing this is the device filtering traffic at the trust boundary. This device is also commonly performing the NAT function. One could argue if a compromise happens it will still limit an attackers internal knowledge but this is also moot given methods to validate NAT by simply initiating an outbound connection.
2.) PAT can provide security by preventing unwanted inbound sessions from reaching the end device. That is not the primary focus of PAT however and comes along as a side consequence of PAT and its use of port numbers. This is a great feature to leverage but it is not a replacement for any sort of end-to-end security. The RFC link below helps cover this as well.
3.) Operationally, NAT breaks the End-to-End connectivity principle that is inherent in the original intentions of the internet. This means the source and destination are transparently connected to each other and do not have fate-sharing or state captured in transit. Boiling that down it means the transit path between a source and destination can be modified, on the fly, as requirements dictate without the source or destination being aware or caring. Failure of a portion of the transit should have no bearing on the sessions in flight (as long as alternative paths exist). Using NAT puts state into the network – for a session to work properly between two end points it MUST transit through a single point that can fix the IP addressing up and ensure each side sees the IP it expects. Additionally, further “fixups” are required to solve for problems associated with applications relying on End-to-End transparency (such as DNS). These fixups induce further state in the network. Adding state to a network always increases the complexity and reduces reliability – always. Additionally, this creates a single point of failure (SPoF) around the NAT device. Further complexity can be added to help mitigate this (firewalls with sessions sharing/state replication, etc) but this will only add further complexity and a further reduction in reliability. This complexity (in using NAT) cannot be reduced – the placement of it can only be moved around the environment.
4.) IPv6, and its drastically increased available pool of IPs, has placed many operators back into the world without NAT. This has proven the inherent security situation and provided an additional benefit of speed. Large scale experiments by content providers have shown the speed improvements that are possible when middle-boxes are eliminated and the processing times etc of NAT are removed from the equation.
5.) In sum, NAT is traditionally associated with security because the devices performing it work at a trust boundary already (and this is required as outlined in RFC2663 to avoid breaking some types of traffic). While there are minor security benefits associated with obfuscation as shown in #1 these are commonly eliminated for externally facing servers. As such, the strength of NAT is the strength of the device performing it at the trust boundary and not inherent to the NAT function itself. The addition of NAT adds state to the network and therefore increases complexity and reduces reliability.
https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/26704-nat-faq-00.html#gen-nat <== Defines NAT as an IP address conservation method while framing the security benefit correctly (in my opinion).
https://tools.ietf.org/html/rfc2663 <== RFC specifically handling NAT. Document is awesome and clarifies NAT, if not part of an existing trust boundary, does not provide a security benefit. I’d recommend section 9.0 which goes through security considerations in greater depth.
https://tools.ietf.org/rfc/rfc4864.txt <== IPv6 specific commentary in relation to NAT (and how it is not needed).
https://www.ietf.org/rfc/rfc3439.txt <== Guidelines and Philosophy covering End-to-End principle.
https://teamarin.net/2019/06/25/why-is-ipv6-faster/ <== Very new document talking about IPv6 as faster mainly due to lack of NAT.