Routing and PREROUTING

Routing and PREROUTING

[Erik Wikström]

Hi again

I'm probably thinking to much here but I've got a bit of a problem with
allowing traffic from my local network out to the Internet. Currently
I've got the following rules which should do that:

# Allow traffic from LAN to WAN
$IPT -t nat -A PREROUTING -i $LAN -s $LOCAL_NET -j ACCEPT
$IPT -t filter -A FORWARD -i $LAN -o $WAN -s $LOCAL_NET -j ACCEPT
$IPT -t nat -A POSTROUTING -o $WAN -s $LOCAL_NET -j MASQUERADE

My problem is with the first rule, where I'm uding the "nat" table but
I'm not doing any NATing, more like filtering since I only pass some
packets. And filtering is not supposed to be done in the "nat" table but
on the other hand there is no filter table in PREROUTING.

But the alternative would be to have a ACCEPT policy in the
PREROUTING-chain and do all the filtering in the FORWARD-chain, which is
kind of unnecessary since a number of packets would then have to travel
through a number of rules (larger than the number of rules in the
PREROUTING-chain) just to be droped in the end. So is my rule OK to use
or would you do in any other way?

--
Erik Wikström

Re: Routing and PREROUTING

[Antony Stone]

On Monday 12 July 2004 3:58 pm, Erik Wikström wrote:

> Hi again
>
> I'm probably thinking to much here but I've got a bit of a problem with
> allowing traffic from my local network out to the Internet. Currently
> I've got the following rules which should do that:
>
> # Allow traffic from LAN to WAN
> $IPT -t nat -A PREROUTING -i $LAN -s $LOCAL_NET -j ACCEPT

This makes me *very* suspicious - why do you have an ACCEPT rule in a nat 
table?

I hope it doesn't mean you have a DROP policy....?

nat tables are for doing Network Address Translation, not for filtering.   
ACCEPT is a filtering action.

> $IPT -t filter -A FORWARD -i $LAN -o $WAN -s $LOCAL_NET -j ACCEPT
> $IPT -t nat -A POSTROUTING -o $WAN -s $LOCAL_NET -j MASQUERADE

Those two look fine to me.

> My problem is with the first rule, where I'm using the "nat" table but
> I'm not doing any NATing, more like filtering since I only pass some
> packets. And filtering is not supposed to be done in the "nat" table but
> on the other hand there is no filter table in PREROUTING.

Okay, so at least you recognise that you shouldn't be doing it...

> But the alternative would be to have a ACCEPT policy in the
> PREROUTING-chain and do all the filtering in the FORWARD-chain,

Correct :)

> which is kind of unnecessary since a number of packets would then have to
> travel through a number of rules (larger than the number of rules in the
> PREROUTING-chain) just to be droped in the end.

What's the problem with that?

> So is my rule OK to use or would you do in any other way?

The absolutely important, vital, essential point is not to have a default DROP 
policy in a nat table (eg PREROUTING), as the system simply will not work if 
you do.

Since you are not allowed to have a default DROP policy, it makes it kind of 
pointless to have ACCEPT rules....

Stick to what you know is right - do NAT in the nat tables, and do Filtering 
in the filter tables :)

Regards,

Antony.

-- 
The difference between theory and practice is that in theory there is no 
difference, whereas in practice there is.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Routing and PREROUTING

[John A. Sullivan III]

Erik Wikström wrote:
> Hi again
> 
> I'm probably thinking to much here but I've got a bit of a problem with
> allowing traffic from my local network out to the Internet. Currently
> I've got the following rules which should do that:
> 
> # Allow traffic from LAN to WAN
> $IPT -t nat -A PREROUTING -i $LAN -s $LOCAL_NET -j ACCEPT
> $IPT -t filter -A FORWARD -i $LAN -o $WAN -s $LOCAL_NET -j ACCEPT
> $IPT -t nat -A POSTROUTING -o $WAN -s $LOCAL_NET -j MASQUERADE
> 
> My problem is with the first rule, where I'm uding the "nat" table but
> I'm not doing any NATing, more like filtering since I only pass some
> packets. And filtering is not supposed to be done in the "nat" table but
> on the other hand there is no filter table in PREROUTING.
> 
> But the alternative would be to have a ACCEPT policy in the
> PREROUTING-chain and do all the filtering in the FORWARD-chain, which is
> kind of unnecessary since a number of packets would then have to travel
> through a number of rules (larger than the number of rules in the
> PREROUTING-chain) just to be droped in the end. So is my rule OK to use
> or would you do in any other way?
> 
> --
> Erik Wikström
Hmmm . . . someone correct me if I'm wrong but I think your first rule 
will end processing in the nat table but the packet will still pass to 
the FORWARD table where, if it does not match a rule, it will be handled 
by your FORWARD chain policy - John
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net

Re: Routing and PREROUTING

[Antony Stone]

On Monday 12 July 2004 4:18 pm, John A. Sullivan III wrote:

> Hmmm . . . someone correct me if I'm wrong but I think your first rule
> will end processing in the nat table but the packet will still pass to
> the FORWARD table where, if it does not match a rule, it will be handled
> by your FORWARD chain policy - John

That is correct.

If you ACCEPT packets in the PREROUTING nat table, they will proceed to the 
FORWARD filter table and start trundling through your ruleset.

If you DROP packets in the PREROUTING nat table, all sorts of things are 
likely to break (depending on how indiscriminate your DROP policy is).

Antony.

-- 
"When you talk about Linux versus Windows, you're talking about which 
operating system is the best value for money and fit for purpose. That's a 
very basic decision customers can make if they have the information available 
to them. Quite frankly if we lose to Linux because our customers say it's 
better value for money, tough luck for us."

 - Steve Vamos, MD of Microsoft Australia

                                                     Please reply to the list;
                                                           please don't CC me.