Ricardo J. Méndez
mendezster at gmail.com
Thu Aug 4 20:42:32 CEST 2005
> > The roule should look like this:
> > iptables -t nat -A PREROUTING -d 126.96.36.199 -p tcp --dport 80 -j DNAT
> > --to-destination 192.168.1.202
> Actually, I believe that --to is a valid unique prefix for
> --to-destination. The fact that it didn't flag as a syntax error
> supports this.
Agreed. Webmin's IPTables interface displays the rule properly as
well, so --to is a valid substitute.
> The problem is that locally generated packets (from the firewall
> itself) to 188.8.131.52 never pass through filter.PREROUTING.
But I 'm testing this from a desktop on the network, not the firewall
itself. PREROUTING should apply to those packets, correct?
> forwarded port may need up to four rules to NAT all access. The
> script I use (at http://www.curby.net/doc/curbywall ) is an example of
> using all four, though it may be difficult to understand.
>From what I can see from the script, besides creating 1 PRE DNAT and
up to 2 POST SNAT rules (one for the internal network and one for the
de-militarized zone), cw_forwardin is creating also an OUT rule for
the destination IP. It also seems that the SNAT rule for the
internal network is using the ip address for the iptables machine as
Assuming that last one is correct, would that still be the IP address
used for SNAT on the scenario I'm faced with? IE, doing DNAT/SNAT for
a machine internal to the network, redirecting to it the requests that
come from our network to a web server outside of it.
(Am I missing something? It's a bit difficult to read, now having
that much experience with bash scripts)
> Other folks here are proponents of running a local DNS server so you
> don't have to do such NAT contortions.
Indeed, it's an approach we considered, but we need this to work with
some internal apps that access the IP address directly.
Ricardo J. Méndez
More information about the netfilter