Re: Iptables is driving me nuts (beginner)
"n/a" <test@pandora.be> writes:
>
> Apparently there's something i'm not getting thru my thick skull about
> packet filtering.
I think others have pointed out the main problem---packets being
forwarded by the machine don't pass through the INPUT and OUTPUT
chains. This behaviour differs from the old "ipchains" behaviour: see
iptables(8), the section titled "COMPATIBILITY WITH IPCHAINS". If
you're trying to build your tables based on old "ipchains" examples,
you'll run into trouble.
> Could someone explain to me in text (no diagrams) how a
> packet is evaluated and then processed tru the chains, also what is done and
> not-done any more after a packet has passed thru a chain.
There's a good explanation in the Netfilter Hacking HOWTO:
http://www.netfilter.org/documentation/HOWTO//netfilter-hacking-HOWTO.html
though it uses a couple of ASCII diagrams.
In a nutshell, the kernel networking code includes several netfilter
"hooks" where packets can be examined, dropped, modified, rerouted, or
whatever.
An IP packet arriving on any interface (even the loopback interface)
is first passed to the NF_IP_PRE_ROUTING hook. This happens even
before the kernel decides whether the packet is destined for a local
process or needs to be forwarded to another machine.
Next, the packet enters the kernel routing code which decides what to
do with it. Packets directed at a local IP address pass through the
NF_IP_LOCAL_IN hook. After this, they are dealt with by the kernel in
the "usual" manner (including passing the data up to an appropriate
user process). Packets that must be forwarded don't pass through this
hook. Instead, they pass through the NF_IP_FORWARD hook, then through
the NF_IP_POST_ROUTING hook, and then to the appropriate device
driver.
Locally generated packets are handled first by the routing code before
being passed to the NF_IP_LOCAL_OUT hook (which can change their
routing) and then the NF_IP_POST_ROUTING hook, and then to the
appropriate device.
The upshot is this: Packets arriving from a different machine and
directed at one of the firewall's IP addresses pass through the
NF_IP_PRE_ROUTING and NF_IP_LOCAL_IN hooks. Packets arriving from a
different machine that must be forwarded to another machine pass
through the NF_IP_PRE_ROUTING, the NF_IP_FORWARD, and the
NF_IP_POST_ROUTING hooks. Locally generated packets destined for
another machine pass through the NF_IP_LOCAL_OUT and NF_IP_POST_ROUTING
hooks.
Packets sent from the firewall back into the firewall (e.g., "telnet
localhost") pass out through the NF_IP_LOCAL_OUT and
NF_IP_POST_ROUTING hooks and then back in through the
NF_IP_PRE_ROUTING and NF_IP_LOCAL_IN hooks.
That's all assuming that none of the hooks interfere with the packet.
Since the hooks can drop, modify, or otherwise reroute the packet, the
actual path of a packet can be even more complicated.
The hooks can do all sorts of things. One of the main things they do
is apply the rules that you set with "iptables". If the only table
you configure is the "filter" table, its three chains INPUT, OUTPUT,
and FORWARD, will be applied at the LOCAL_IN, LOCAL_OUT, and FORWARD
hooks. Therefore, packets will only pass through one of the three
filter chains (except packets through the loopback which are processed
by the OUTPUT chain on the way out and the INPUT chain on the way in).
In your case, it looks like you need to do some masquerading for your
internal LAN, so things get a bit more complicated.
If you configure the "nat" table, too, destination NAT (i.e., changing
the destination of a packet) in the "nat" PREROUTING chain is applied
in the PRE_ROUTING hook: a packet arriving from the big, bad Internet
that *seems* to be for the firewall's external IP address could be
*really* for the firewall or it might be for a machine on the internal
LAN. The destination NAT is applied at the PRE_ROUTING stage so that
it can rewrite the destination address before the kernel routing code
makes its decision. Then, it gets passed to LOCAL_IN or FORWARD as
appropriate.
(Destination NAT can also be applied via the "nat" OUTPUT chain in the
OUTPUT hook if you want to redirect locally generated packets for
some reason; and source NAT is applied via the "nat" POSTROUTING chain
in the POST_ROUTING hook after the packet has already passed through
the "filter" OUTPUT or FORWARD chains.)
I hope that helps.
I can't tell from the configuration rules you gave exactly what it is
you're trying to do. It looks like you want internal hosts to be able
to make direct SMTP and POP connections to a certain subnet of
external hosts and web connections to "kottweb", but you want to
prevent all other connections (except web connections proxied through
the firewall).
Can you clarify this?
--
Kevin <buhr@telus.net>
Reply to: