Se você está fazendo portforwarding para a mesma rede, você precisa ter certeza que pacotes de requisição e de resposta passarão pela máquina responsável por NAT (podendo então serem alterados). O código NAT vai agora (desde 2.4.0-test6), bloquear redirecionamento de saída ICMP que ocorre quando o pacote NAT'ed sai pela mesma interface pela qual entrou, mas o servidor que recebeu ainda tentará responder diretamente para o cliente (que não vai reconhecer a resposta).
O caso clássico ocorre quando as máquinas internas tentam acessar o web server `público', que na verdade sofre DNAT do endereço externo (1.2.3.4) para uma máquina interna (192.168.1.1), como descrito abaixo:
# iptables -t nat -A PREROUTING -d 1.2.3.4 \
-p tcp --dport 80 -j DNAT --to 192.168.1.1
Uma maneira é rodar um servidor DNS interno que sabe os endereços IP reais (internos) do seu web site público, e repassa todas as outras requisições para um servidor DNS externo. Isso significa que o log no seu web server mostrará os endereços IP internos corretamente.
A outra forma é dizer à máquina responsável por NAT que mapeie o endereço IP de origem para o seu próprio nessas conexões. Nesse exemplo, faríamos o seguinte (assumindo que o endereço interno da NAT box seja 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
Devido ao fato de que a chain PREROUTING é analizada antes, os pacotes já estarão destinados para o web server interno: podemos dizer quais conexões têm origem interna pelo endereço IP de origem.