Si vous effectuez de la redirection de port vers le même réseau, vous devrez vous assurer que les paquets futurs et leurs réponses passeront par la machine de NAT (pour qu'ils soient modifiés). Le code du NAT (depuis le noyau 2.4.0-test6) bloquera le paquet de redirection ICMP sortant qui est généré lorsque le paquet modifié sort par l'interface par laquelle il est entré, mais le serveur de réception essaiera toujours de répondre directement au client (qui ne reconnaitra pas la réponse).
Dans le cas classique, les machines internes essaient d'accéder à votre serveur web `public', qui en réalité est redirigé par DNAT de l'adresse publique (1.2.3.4) vers une machine interne (192.168.1.1), comme ceci :
# iptables -t nat -A PREROUTING -d 1.2.3.4 \
-p tcp --dport 80 -j DNAT --to 192.168.1.1
Une solution est d'utiliser un serveur DNS interne qui connaît l'adresse IP réelle (interne) de votre site web public, et de rediriger toutes les autres requêtes vers un serveur DNS externe. Ceci signifie qu'une connexion locale sur le serveur web montrera les adresses IP internes correctement.
L'autre solution pour ces connexions est de forcer la machine de NAT à mettre en correspondance les adresses IP sources avec la sienne, trompant le serveur en répondant à travers lui. Dans cet exemple, nous devrions faire ceci (en supposant que l'adresse IP interne de la machine de NAT est 192.168.1.250) :
# iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \
-p tcp --dport 80 -j SNAT --to 192.168.1.250
Comme la règle de PREROUTING est exécutée en premier, les paquets seront déjà destinés pour le serveur web interne : nous pouvons dire lesquels sont générés en interne grâce aux adresses IP sources.