Skip to contentSkip to conversation

Stateless dropping of packets

DISCUSSION Florian Weimer 2 participants 4 messages Apr 1, 2003 – Apr 2, 2003

lore
Share & tools
lore
#0 lore raw

Is it possible to drop packets, preferably using 2.4 iptables, before the packet triggers updates of some caches (e.g. the route cache)?

On one particular host, I saw the route cache explode, despite all packets being dropped (using a DROP rule).

#1 lore raw
Quoted 3 lines · Florian Weimer

Is it possible to drop packets, preferably using 2.4 iptables, before the packet triggers updates of some caches (e.g. the route cache)?

If you DROP the packet in a PREROUTING chain, that should work. Since the "filter" table doesn't have a PREROUTING chain, you need to use a table that does, like the "mangle" table. For example:

        iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP

should drop everything with a source in 10.0.0.0/8 without touching the routing cache.

Signature · 1 line
Kevin <[email protected]>
#2 lore raw
Quoted 11 lines · Kevin Buhr
Quoted 2 lines

Is it possible to drop packets, preferably using 2.4 iptables, before the packet triggers updates of some caches (e.g. the route cache)?

If you DROP the packet in a PREROUTING chain, that should work. Since the "filter" table doesn't have a PREROUTING chain, you need to use a table that does, like the "mangle" table. For example:

        iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP

should drop everything with a source in 10.0.0.0/8 without touching the routing cache.

It does, thanks a lot. *phew* Looks as if I don't have to try some *BSD instead.

Is this extremely important application of the PREROUTING chain documented somewhere? Should I feel embarrassed? 8-)

#3 lore raw
Quoted 3 lines · Florian Weimer

Is this extremely important application of the PREROUTING chain documented somewhere? Should I feel embarrassed? 8-)

No, I haven't seen it documented explicitly. It's just a fortunate side effect of the fact that the DROP target can be used anywhere and there's a fairly general-purpose table ("mangle") that has a PREROUTING chain.

There's no particular reason for the "filter" table *not* to implement PREROUTING and POSTROUTING chains (at least not that I can see) except for a very small performance hit. I guess no one thought there'd be much of a use for them. And it would break the nice rule of thumb that a packet only passes through one of the three chains of the "filter" table (not counting packets throught the loopback interface which pass through OUTPUT then back through INPUT).

Signature · 1 line
Kevin <[email protected]>