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) :
- Les communications entre postes qui se situent derrière des NAT pose un problème, c'est le cas des protocoles pair à pair.
- La fragmentation éventuelle des paquets dans le réseau pose également un problème quand un NAT est traversé, car il n'est pas possible pour un hôte qui reçoit des fragments avec le même fragment id et des adresses IP source identiques d'identifier qu'ils appartiennent en réalité à deux hôtes différents derrière un NAT.
- Certains protocoles, comme rlogin, imposent que le port source soit fixé à 512. La traversée d'un NAT empêche alors plus d'une session sortante par adresse publique.
- IPSec pose également des problèmes lors de la traversée d'un NAT dans la mesure où l'en-tête authentifiée par AH est altérée par le NAT.
- Le protocole X-Window pose également un problème, car les connexions TCP sont initiées par les clients vers le display.
- rsh et rlogin utilisent un socket initié par le serveur vers le client pour l'erreur standard.
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.