From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: netfilter@lists.netfilter.org
Subject: Re: Help with IPtables and NAT
Date: Sat, 22 Jul 2006 02:58:46 +0200 [thread overview]
Message-ID: <44C17846.4080403@plouf.fr.eu.org> (raw)
In-Reply-To: <44C16109.20704@jemconsult.biz>
Hello,
James Marcinek a écrit :
[...]
> This is my latest concoction:
>
> # First drop everything (lets you open what you want)
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -P FORWARD DROP
So far so good.
> iptables -t nat -P PREROUTING DROP
> iptables -t nat -P POSTROUTING DROP
This is wrong, *very* wrong. The 'nat' table is not intended to do any
filtering, so you don't want to set the default policy of any nat chain
to DROP. Trust me. (Sometimes I wonder why the DROP default policy is
allowed in the nat chains.)
> # PREROUTING chain rules
> # iptables -t nat -i PREROUTING 1 -d 172.10.10.2 -j LOG --loglevel debug
> iptables -t nat -A PREROUTING -d 172.10.10.2 -p tcp --dport 80 -j DNAT
> --to-dest 192.168.0.2
> iptables -t nat -A PREROUTING -d 172.10.10.2 -p tcp --dport 443 -j DNAT
> --to-dest 192.168.0.2
[and so on]
Since you want to DNAT 172.10.10.2 to 192.168.0.2, I suggest you write a
single rule for all protocols and ports :
iptables -t nat -A PREROUTING -d 172.10.10.2 -j DNAT --to 192.168.0.2
Then you add rules in the filter FORWARD chain to do the filtering, just
like you did in the filter INPUT chain.
> iptables -t nat -A PREROUTING -d 172.10.10.2 -p udp --dport 53 -j DNAT
> --to-dest 192.168.0.2
> iptables -t nat -A PREROUTING -d 172.10.10.2 -p udp --dport 53 -j DNAT
> --to-dest 192.168.0.2
Here you have twice the same rule. Shouldn't one be for TCP (DNS can use
either TCP our UDP) ?
> # User-defined chain for ACCEPTed TCP packets
> iptables -N okay
> iptables -A okay -p TCP --syn -j ACCEPT
> iptables -A okay -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A okay -p TCP -j DROP
It does not really matter, but I don't fully understant the purpose of
this chain.
> # INPUT chain rules
> iptables -A INPUT -p ALL -i eth1 -s 192.168.0.0/24 -j ACCEPT
> iptables -A INPUT -p ALL -i lo -s 127.0.0.1 -j ACCEPT
> iptables -A INPUT -p ALL -i lo -s 192.168.0.1 -j ACCEPT
> iptables -A INPUT -p ALL -i lo -s 172.10.10.1 -j ACCEPT
> iptables -A INPUT -p ALL -i lo -s 172.10.10.2 -j ACCEPT
You forgot the whole 127.0.0.0/8 subnet which can be used on the
loopback interface. Anyway, why don't you just allow all traffic on the
loopback interface ?
> iptables -A INPUT -p ALL -i eth1 -d 192.168.0.255 -j ACCEPT
Useless : 192.168.0.255 belongs to 192.168.0.0/24.
> # Rules for incoming packets from the Internet
>
> # Packets for established connections
> iptables -A INPUT -p ALL -d 172.10.10.1 -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> iptables -A INPUT -p ALL -d 172.10.10.2 -m state --state
> ESTABLISHED,RELATED -j ACCEPT
If all traffic on 172.10.10.2 is redirected to 192.168.0.2, this last
rule becomes useless.
> # TCP rules
[...]
> # UDP rules
> iptables -A INPUT -p UDP -i eth0 -s 0/0 --destination-port 53 -j ACCEPT
[...]
As DNS can also use TCP, I'd expect a rule accepting TCP port 53.
> # ICMP rules
>
> # FORWARD chain rules
> iptables -A FORWARD -i eth1 -j ACCEPT
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> # iptables -A FORWARD -i eth0 -d 192.168.0.2 -j ACCEPT
Ok, you don't want to accept all traffic redirected to 192.168.0.2. So
you have to add rules to accept some protocols/ports. E.g. :
iptables -A FORWARD -i eth0 -d 192.168.0.2 -p tcp --dport 80 -j ACCEPT
> # OUTPUT chain rules
> iptables -A OUTPUT -p ALL -s 127.0.0.1 -j ACCEPT
> iptables -A OUTPUT -p ALL -s 192.168.0.1 -j ACCEPT
> iptables -A OUTPUT -p ALL -s 172.10.10.1 -j ACCEPT
Same remark as above about 127.0.0.0/8.
By the way, why do you need to filter the source address in OUTPUT ?
This could break things like the REJECT target if you used it.
> # iptables -A OUTPUT -p ALL -s 172.10.10.2 -j ACCEPT
> iptables -t nat -A OUTPUT -d 172.10.10.2 -p ALL -j DNAT --to-destination
> 192.168.0.2
>
> # POSTROUTING
> iptables -t nat -A POSTROUTING -s 192.168.0.2 -j SNAT --to-source
> 172.10.10.2
> iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 172.10.10.1
next prev parent reply other threads:[~2006-07-22 0:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-21 23:19 Help with IPtables and NAT James Marcinek
2006-07-21 23:32 ` Gary W. Smith
2006-07-22 0:58 ` Pascal Hambourg [this message]
2006-07-24 15:16 ` Martijn Lievaart
[not found] ` <42950.2001:888:19e1::53.1153754175.squirrel@dexter>
2006-07-28 10:31 ` Pascal Hambourg
2006-07-22 8:23 ` Guillaume
2006-07-22 10:29 ` Pascal Hambourg
2006-07-22 11:18 ` Guillaume
2006-07-22 14:38 ` James Marcinek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44C17846.4080403@plouf.fr.eu.org \
--to=pascal.mail@plouf.fr.eu.org \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.