netfilter packetflow

netfilter packetflow

[A G]

Hi
This diagram shows the packetflow
http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

1. Does this mean that when I set my computer to bridge mode for example
brctl addbr br0
brctl addif br0 eth1
brctl addif br0 eth2
ip link set br0 up

The packet goes through all of the link layer chains? That is, it will go through nat/PREROUTING (ebtables), raw/PREROUTING (iptables), mangle/PREROUTING (iptables)
Or does it only go through the ebtables (blue coloured) chains in the link layer?

2. If it only goes through the blue chains only, if I want it to go through the iptables chains in the link layer (green coloured), I am required to have a rule with a DROP target to push it up to to the higher network layers, is this correct?

3. In which case, if I have added rules to the mangle/PREROUTING (iptables) chain, am I adding it to the network layer mangle/PREROUTING box in the diagram, or in the link layer mangle/PREROUTING box in the diagram?

Currently I'm learning how it all fits together, thanks
Andrew
 		 	   		  

Re: netfilter packetflow

[Jan Engelhardt]

On Friday 2012-08-17 14:48, A G wrote:

>This diagram shows the packetflow
>http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
>
>1. Does this mean that when I set my computer to bridge mode for 
>example The packet goes through all of the link layer chains? That is, 
>it will go through nat/PREROUTING (ebtables), raw/PREROUTING 
>(iptables), mangle/PREROUTING (iptables) Or does it only go through the 
>ebtables (blue coloured) chains in the link layer?

If the "net.bridge.bridge-nf-call-ip6tables" sysctl is enabled (this is 
the defualt), it will go through both blue boxes and green boxes. If 
disabled, only blue boxes will be processed in the blue layer.

>2. If it only goes through the blue chains only, if I want it to go 
>through the iptables chains in the link layer (green coloured), I am 
>required to have a rule with a DROP target to push it up to to the 
>higher network layers, is this correct?

Using DROP in broute would indeed be the necessary prerequisite, 
however, that will force routing and deactivate bridging for the packet.

old question revisited: can rely in 'iptables-restore' format?

[Peter Grandi]

Perhaps it is useful to ask again an old question:

Is the format of files produced by 'iptables-saved' and consumed
by 'iptables-restore' still considered an internal, undocumented
format that may change at any time?

How stable is in practice that format?

Because I reckon that format has been stable for at least 10
years, and I wonder whether it may be desirable to write
firewall configurations directly in it, rather than using long
'iptables' command shell scripts.

Re: old question revisited: can rely in 'iptables-restore' format?

[/dev/rob0]

On Tue, Aug 21, 2012 at 12:26:57AM +0100, Peter Grandi wrote:
> Perhaps it is useful to ask again an old question:
> 
> Is the format of files produced by 'iptables-saved' and consumed
> by 'iptables-restore' still considered an internal, undocumented
> format that may change at any time?
> 
> How stable is in practice that format?
> 
> Because I reckon that format has been stable for at least 10
> years, and I wonder whether it may be desirable to write
> firewall configurations directly in it, rather than using long
> 'iptables' command shell scripts.

I can't say why there's no official iptables-save(5) manual page, 
but I can definitely say that it IS desirable and recommended to
use iptables-restore rulesets in your boot sequence. Most major 
distros that provide rulesets do use iptables-save and 
iptables-restore, and this has been the case for many years.

The main benefit is that iptables-restore is atomic. All changes
are committed in one pass. Any error in the ruleset means your 
existing ruleset is not replaced.

iptables OTOH has to read and rewrite the entire ruleset for each 
command given, and there is a potential for race conditions if a 
script is triggered to run before the previous run completed.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: old question revisited: can rely in 'iptables-restore' format?

[Neal Murphy]

On Monday 20 August 2012 20:30:26 /dev/rob0 wrote:
> The main benefit is that iptables-restore is atomic. All changes
> are committed in one pass. Any error in the ruleset means your
> existing ruleset is not replaced.

[Minor digression]
By 'atomic', do you mean that all of the changes are made with a single 
COMMIT, regardless of how many tables are accessed and regardless of how many 
rules are processed?

It's been my experience that there is an implicit COMMIT at every table 
change, and there is a ballpark limit of around 20,000 rules per commit. Thus:
  - if the file you are feeding to iptables-restore references one table only
    and contains fewer than around 20,000 rules, the operation will be atomic.
  - if the file you are feeding to iptables-restore references more than one
    table and contains fewer than around 20,000 rules per table, then only the
    changes *per table* will be atomic.
  - If the changes to a table contain more than around 20,000 rules, then 
    that operation will require more than one COMMIT and will NOT be atomic.

When relatively small change sets are involved, I agree that iptables-restore 
is atomic. But when very large change sets are involved, I disagree: iptables-
restore is *not* necessarily atomic. To be pedantic, it would be correct to 
say that iptables-restore operates atomically only under certain conditions.

N

Re: old question revisited: can rely in 'iptables-restore' format?

[/dev/rob0]

On Mon, Aug 20, 2012 at 10:21:37PM -0400, Neal Murphy wrote:
> On Monday 20 August 2012 20:30:26 /dev/rob0 wrote:
> > The main benefit is that iptables-restore is atomic. All changes
> > are committed in one pass. Any error in the ruleset means your
> > existing ruleset is not replaced.
> 
> [Minor digression]
> By 'atomic', do you mean that all of the changes are made with a 
> single COMMIT, regardless of how many tables are accessed and 
> regardless of how many rules are processed?

I don't know. I was hoping that someone familiar with the source 
would answer.

> It's been my experience that there is an implicit COMMIT at every 
> table change, and there is a ballpark limit of around 20,000 rules 
> per commit. Thus:

>   - if the file you are feeding to iptables-restore references one
>     table only and contains fewer than around 20,000 rules, the
>     operation will be atomic.

>   - if the file you are feeding to iptables-restore references more
>     than one table and contains fewer than around 20,000 rules per
>     table, then only the changes *per table* will be atomic.
>   - If the changes to a table contain more than around 20,000 rules,
>     then that operation will require more than one COMMIT and will
>     NOT be atomic.
> 
> When relatively small change sets are involved, I agree that 
> iptables-restore is atomic. But when very large change sets are 
> involved, I disagree: iptables-restore is *not* necessarily 
> atomic. To be pedantic, it would be correct to say that 
> iptables-restore operates atomically only under certain
> conditions.

Interesting, thanks. I think my post was right in the usual case, 
however, and that your examples of >20K rules might be better
handled by ipset(8).
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: old question revisited: can rely in 'iptables-restore' format?

[Jan Engelhardt]

On Wednesday 2012-08-22 19:35, /dev/rob0 wrote:

>On Mon, Aug 20, 2012 at 10:21:37PM -0400, Neal Murphy wrote:
>> On Monday 20 August 2012 20:30:26 /dev/rob0 wrote:
>> > The main benefit is that iptables-restore is atomic. All changes
>> > are committed in one pass. Any error in the ruleset means your
>> > existing ruleset is not replaced.
>> 
>> [Minor digression]
>> By 'atomic', do you mean that all of the changes are made with a 
>> single COMMIT, regardless of how many tables are accessed and 
>> regardless of how many rules are processed?
>
>I don't know. I was hoping that someone familiar with the source 
>would answer.

COMMIT is for each table separately, hence the atomicity is also at the 
table level.

>> It's been my experience that there is an implicit COMMIT at every 
>> table change, and there is a ballpark limit of around 20,000 rules 
>> per commit. Thus:

There is an upper limit, each table can be at most 4 GB in size. But it 
will *always* be atomic - that is to say, an incoming packet will 
always have some table (either the old, or its replacement) to be 
processed with.

The most massive real-world ruleset to date has been Jesper's
with 662160 rules (in 151426 chains) weighing in at "only" 149 MB.

>>   - If the changes to a table contain more than around 20,000 rules,
>>     then that operation will require more than one COMMIT and will
>>     NOT be atomic.

No no no..

Re: old question revisited: can rely in 'iptables-restore' format?

[Peter Grandi]

>> Is the format of files produced by 'iptables-saved' and consumed
>> by 'iptables-restore' still considered an internal, undocumented
>> format that may change at any time?

>> How stable is in practice that format?
   ======================================

>> Because I reckon that format has been stable for at least 10
>> years, and I wonder whether it may be desirable to write
>> firewall configurations directly in it, rather than using long
>> 'iptables' command shell scripts.

> I can't say why there's no official iptables-save(5) manual page, 
> but I can definitely say that it IS desirable and recommended to
> use iptables-restore rulesets in your boot sequence. Most major 
> distros that provide rulesets do use iptables-save and 
> iptables-restore, and this has been the case for many years.

That's a misunderstanding of the question I asked, which was not
at all whether using 'iptables-restore' is desirable or common.

The question is whether the syntax accepted by 'iptables-restore'
format is going to be stable, so that one might invest in
generating rulesets from programs other than 'iptables-save',
rather than running many 'iptables' commands, then 'iptables-save'
and then 'iptables-restore'.

The only "guarantee" that I have seen is that whatever is output
by 'iptables-save' will be accepted by 'iptables-restore', and
that the syntax may be changed at any time.

However in practice the syntax accepted by 'iptables-restore' has
not substantially changed for many years.

Re: old question revisited: can rely in 'iptables-restore' format?

[Jan Engelhardt]

On Thursday 2012-08-23 21:20, Peter Grandi wrote:
>>> How stable is in practice that format?
>   ======================================

The format has been valid for longer than any of us can remember,
and there is no need to change it.