At 07:35 28/02/01 +0100, Reckhard, Tobias wrote:
> > Generally, NAT is "near" the interface on which it applies. So:
> > - at input stage, NAT is applied before filtering
> > - at output stage, NAT is applied after the filtering.
> >
>How general is this information, mouss? It doesn't hold true for Linux IP
>Masquerading (at least up to the 2.2 series kernels), AFAIK. I don't know
>about other implementations, but ipmasq is a variation of IP forwarding in
>Linux ipchains.
It's more of a logical "rule" order than a rigourous one.
It is either imposed by the implementation (ipf/ipnat calls are hardcoded), or
by configuration when the admin defines the rules. In the latter, there are
exceptions (such as anti-spoofing rules when you just want to drop those silly
packets), but for packets that you want to pass through NAT and filtering,
you'll
generally need to follow the above rule.
A simple principle to state these rules is:
It is better that every module except NAT sees the real addresses.
Let's take an example. assume you have a 10.* internal network, that you
map to 1.2.3.4
(let's say this is your FW external address).
for an outbound packet, it is preferable that it is translated at the last
step, just before being
forwarded. this explains why NAT at output is the last step.
for an incoming packet, you need to check whether it corresponds to a NAed
one and map
it back, so that the ip stack and other modules (including filter, QoS,
IDS, ...) see the unmaped
address, instead of the maped one.
> > Let's concentrate on input filtering (My guess is this is the case that
> > you consider).
> > The reason why you NAT first is that only then can the filter know the
> > effective destination.
> > If you filter before, you might have a situation where all packets are
> > going
> > to your FW's external address, since they haven't yet been mapped back
> > to the private IP address where they're to go.
> >
>You're differentiating between outbound NAT traffic (output stage) and the
>return packets (input stage) here, which is a bit confusing.
Sorry for the confusion. by "input filtering", I was meaning a filter that
only acts
at input. the "only then" stuff applies to inbound traffic that is a
response to
a previous outbound packet.
>Well, the Linux kernel's packet filtering code works that way. In kernels up
>to 2.2, every packet taverses three steps: input, forward and output. You
>can apply basic filtering rules (i.e. accept, deny, reject) at all three
>stages. The forwarding stage is enhanced by a PAT action and allows you to
>redirect packets to other ports and addresses (I'm not sure on that last
>bit, since I've never used it myself). Note that if you use PAT/ipmasq, you
>don't need to define a forwarding rule for return traffic. BTW, Linux
>ipchains (the 2.2 PF code) is not stateful (save ipmasq).
ipfw works this way too, but it's FreeBSD specific, that's why I prefer
ipf, though it has
things I don't like.
not yet been through iptables, but I guess it'll replace ipchains once it
is fully stable
and provided with the linux dists, no?
>In Linux (2.2), there is no decision, NAT/PAT/ipmasq is part of the kernel's
>packet filtering code and is configured in the 'forward' chain.
In my understanding, you still choose the order. the "forward" word is
(still in
my understanding) used for packets that come from the net and go to the net,
not because you go through the "ip forward" stage. Well, these go through this
stage, but I mean the "input" and "output" do not apply to packets that are to
be forwarded. Am I right/wrong? if I'm right, then the order is configurale.
> Of course,
>you could always use two boxes, one filtering and the other ipmasqing, in
>which case I'd probably always filter before ipmasqing, since the ipmasq box
>will NAT anything (it doesn't filter in this setup) and the filtering box
>couldn't really make much of a decision based on source information..
>Lesson: always also filter on Linux ipmasq boxes.
I fully agree. I'd say: always filter on your gateway to the internet.
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
