Se si sta effettuando il portforwarding all'interno della stessa rete, ci si dovrà assicurare che sia i pacchetti inviati sia i pacchetti in risposta attraversino la NAT box (in questo modo potranno essere alterati). Il codice NAT ora (sin dalla 2.4.0-test6) blocca il pacchetto ICMP redirect in uscita, il quale viene prodotto quando il pacchetto modificato utilizza la stessa interfaccia da cui è arrivato, tuttavia il server ricevente cercherà comunque di rispondere direttamente al client (il quale non riconoscerà la risposta).
Il caso classico è quello che vede lo staff interno cercare di accedere al vostro web server `pubblico', il quale è attualmente sottoposto al DNAT dall'indirizzo pubblico (1.2.3.4) verso una macchina interna (192.168.1.1), come in questo caso:
# iptables -t nat -A PREROUTING -d 1.2.3.4 \
-p tcp --dport 80 -j DNAT --to 192.168.1.1
Una possibile soluzione consiste nell'utilizzare internamente un server DNS che conosca l'indirizzo IP reale (interno) del vostro sito web pubblico, e che provveda inoltre a inoltrare tutte le altre richieste verso un server DNS esterno. Ciò significa che le registrazioni sul vostro server web presenteranno correttamente gli indirizzi IP interni.
L'altra possibile soluzione consiste nel far sì che la NAT box mappi per queste connessioni l'indirizzo IP sorgente con il proprio, ingannando in questo modo il server, il quale invierà le risposte attraverso di esso. In questo caso si dovrebbe utilizzare (assumendo che l'indirizzo IP interno della NAT box sia 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
Siccome la regola PREROUTING viene eseguita per prima, i pacchetti avranno già come destinazione il server web interno: si potranno riconoscere quali sono stati internamente modificati in base agli indirizzi IP sorgenti.