Bien que certaines applications s'en accommodent sans difficulté, le NAT n'est pas transparent vis à vis des applications du réseau et reporte une complexité additionnelle sur le fonctionnement des applications (RFC 2993, RFC 3027) :
Un problème majeur se pose lorsqu'un protocole de communication transmet l'adresse IP de l'hôte source dans un paquet, ou des numéros de ports. Cette adresse n'étant pas valide après avoir traversé le routeur NAT, elle ne peut être utilisée par la machine destinataire. Ces protocoles sont dits « passant difficilement les pare-feu », car ils échangent au niveau applicatif (FTP) des informations du niveau IP (échange d'adresses) ou du niveau TCP (échange de ports), ce qui transgresse le principe de la séparation des couches réseaux.
Quelques protocoles de ce type sont : FTP, H.323, les protocoles faisant du poste-à-poste (IRC-DCC), les protocoles de gestion de réseau, DNS, certains messages ICMP, traceroute), le protocole SIP.
Pour pallier cet inconvénient, les routeurs NAT doivent inspecter le contenu, ils font alors office de passerelle applicative (Application-Level Gateway, ALG) et manipulent des paquets qui les traversent pour remplacer les adresses IP spécifiées par les adresses externes. Cela implique de connaître le format du protocole.
Le NAT ne fait que participer à la politique de sécurité du site, et ce n'est pas son objectif principal : une fois la traduction établie, elle est bidirectionnelle. Le NAT n'est donc pas un substitut au pare-feu.
L'IETF décourage le NAT avec IPv6 en raison des problèmes inhérents et du fait que l'espace d'adresse IPv6 est tel que l'économie d'adresse n'est pas nécessaire.
À défaut de configuration explicite, les NAT rejettent généralement les connexions entrantes, ce qui cause des problèmes notamment pour les applications pair à pair.
Deux protocoles ont été développées pour permettre à des postes clients de demander l'ouverture et la redirection de ports déterminés au routeur NAT :