"raw" table versus "filter" table

"raw" table versus "filter" table

[David TAILLANDIER - DIGI VALUE]

Hi,

according to the well-known netfilter schematic:
http://inai.de/images/nf-packet-flow.png
the "raw" table is processed before the "filter" table.

I tested it with some usual commands without problem:
    iptables --table raw --append PREROUTING --source 1.2.3.4 --jump REJECT
    iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT

- the packets are handled sooner, without the need to go though
  conntrack+mangle+nat+routing. So less CPU/memory stress (and in turn
  lightly compensated by the fact the iptable_raw module has to be
  loaded ?)
- only one rule in case the box is also a router (won't be ok for
  every rules, obviously) because there is no need to add the same rule
  for filter/forward

The documentations I found always describe the raw table to be used in
strict cases. But none give even the smallest justification.

--> Is there any reasons not to use the raw table, apart dogmatic ones ?

Re: "raw" table versus "filter" table

[Neal P. Murphy]

On Wed, 18 Nov 2015 22:47:02 +0100
David TAILLANDIER - DIGI VALUE <david.taillandier@digi-value.fr> wrote:

> 
> Hi,
> 
> according to the well-known netfilter schematic:
> http://inai.de/images/nf-packet-flow.png
> the "raw" table is processed before the "filter" table.
> 
> I tested it with some usual commands without problem:
>     iptables --table raw --append PREROUTING --source 1.2.3.4 --jump REJECT
>     iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT
> 
> - the packets are handled sooner, without the need to go though
>   conntrack+mangle+nat+routing. So less CPU/memory stress (and in turn
>   lightly compensated by the fact the iptable_raw module has to be
>   loaded ?)
> - only one rule in case the box is also a router (won't be ok for
>   every rules, obviously) because there is no need to add the same rule
>   for filter/forward
> 
> The documentations I found always describe the raw table to be used in
> strict cases. But none give even the smallest justification.
> 
> --> Is there any reasons not to use the raw table, apart dogmatic ones ?

Don't have an answer, but I'll have to look into 'raw' for Smoothwall Express. I'll use pert near *anything* that will reduce 'wasteful' CPU load. Combined with ipset, it should be possible to drop all packets to and from 'banned' public IPs using fewer CPU cycles. I already drop INVALID in mangle:PREROUTING. Dropping packets to and from banned addresses in raw:PREROUTING and rejecting packets to banned IPs in raw:OUTPUT would reduce unneeded processing. Of course, this idea depends on whether ipset can be used in the raw table.

One drawback is that NAT doesn't have a chance to re-address these packets. But this might not be too bad, since one doesn't want any traffic to or from banned IPs anyway.

Neal

Re: "raw" table versus "filter" table

[Pascal Hambourg]

David TAILLANDIER - DIGI VALUE a écrit :
> 
> The documentations I found always describe the raw table to be used in
> strict cases. But none give even the smallest justification.
> 
> --> Is there any reasons not to use the raw table, apart dogmatic ones ?

Any match that requires conntrack, NAT or routing to be applied won't
work in the raw table. Only simple rules are possible.