something to do with established accepting packets as part of a connection that might be closed. you'll notice that they stay in the connection tracking table even after they aren't valid anymore.
actually, AFAIR, just presence in ConnTrack table doesn't mean 'established'. if, according to conntrack table, connection is already closed, then data frames should be considered invalid, for example
To me it seemed after this post discussion starts drifting a bit off topic.
First of all, abcwarbot sets up firewall to protect his router. Meaning the rules discussed later in this topic are to be on the input chain. Since this has normally spoken not a lot of traffic and certainly not traffic from client to internet and vice versa I don't see it slowing down traffic flow ´through´ the router.
I have the invalid/esthablished etc rules only on the input chain and they get so little traffic its hardly worth looking at..
When we are talking rules on the forward chain for traffic passing through router things are different. How is now the story with "invalid"? If the router is not processing (QoS, shaping, virus filter) the traffic flow then all traffic can be just passed through. I have several routers doing so and they have no filter or mangle rules whatsoever on the forward chain. All router does do is routing. Some traffic that could be "invalid" might as well be passed through as well. Probably faster then filter all traffic just to catch some invalid packages....
So why filter invalid, established etc in forward? It slows down the traffic flow but doesn't protect router. Protection is done in input. At best these forward rules protect next router or device. But let that router or device handle its own protection! This way cpu power is balanced over the network?
Apart of that, indeed the filter rules, or mangle rules, are best located such that the rules getting the bulk of traffic are placed first. BUT, there is always a "but".
I use L7 filter for Skype and some P2P. Since these filters are having long signature keys, special Skype, I basically want as little traffic as possible to run through this filters. So I try to filter out as much as other traffic out of the process before package stream hits the L7 filters.
Also, packages that I want to pass router as fast as possible, like ping, dns, etc. I put high in the filters. The earlier they leave the process the earlier they are forwarded by the router to the interface.
And, the good reader now understands that although Skype L7 filter (we are talking mangle here) is placed low because I want other traffic filtered away first, the fact it is ´real live´ traffic means it should also be as fast as possible and thus leaving filter process as fast as possible. So this would mean placing it high in the sequence. That is then in contrast to my first conclusion.
In other words, it is very much depending on what you want and what traffic is passing and processed by router.
When it comes to speed of traffic several other factors come in play too. Maybe off topic here but don't forget about these! Some examples:
How is routing, or bridging take place in network? Low utilised network is fast in bridge mode while high utilised benefits more from routing.
How much traffic is carried by network while it will be dropped somewhere anyway? Better drop it at source then 4 nodes away. Special on wireless links important!
QoS. On congested links and routers if all traffic passes un-orderly latency for speed demanding packaged goes up only because low speed demand package have same order in passing. Put a Ferrari in a traffic jam and he is nothing faster then the horse and wagon beside him!
And last, but not least. Fast routers handle traffic faster then low rated ones. Ferrari has only benefit on the highway. Put him on sand track and again he is nothing faster then horse and wagon....
Still a very interesting discussion though, I just wanted to add some other intake as well.