On Thu, Apr 25, 2002 at 10:41:52AM -0700, Don Cohen wrote: > > My impression (please correct me if I'm wrong) is that pre is supposed > to catch packets coming into the box and post is supposed to catch > those going out. > > I believe postrouting currently happens before a packet is queued for > output. I think it would be better to delay this until after it is > dequeued. This would improve accuracy. In particular, the packets > that are dropped in queuing should not be processed as outgoing. > > I'm interested in hearing any counter arguments, and especially things > that would be broken by this change.
the counter argument is that the queue is part of the lower-layer drivers and not part of the IPv4 stack. netfilter hooks are always restricted to one protocol stack - there's separate hooks for ipv4, ipv6, ipx, ... > BTW, I'm trying to find out by reading the code, but it would help > if I could just find some documentation, or for that matter if someone > would just tell me the answers. What code is actually run at which > places? At the moment I'm mostly interested in conntrack and nat. > I understand why dnat has to be done pre-routing. I don't see why > snat couldn't also be done there. theoretically, yes. but then you wouldn't be able to match on the original source of the packet anymore (imagine the standard masquerading case, you wouldn't be able to distinguish your individual clients, because all the source adresses have already been overwriten). > It occurs to me that when you start > taking drops into account, conntrack could/should really track at > least two different states, and maybe more. The real question is > what states the two different ends of the connections could be in. This is an extremely complex situation, and the connection tracking code cannot assume that a packet seen by the packet filter will ever arrive at the receiver. > The packets that come in show something about the state the sender > was in when it sent those packets, the packets that go out tell us > something about what states the receiver could be in after receiving > them (if it does receive them). Any pointers to discussion of these > issues are appreciated. Not sure if there was any public discussion about this. As you are talking about TCP, maybe Jozsef Kadlecsik (who has done a lot of state trackin improvements by writing the window tracking code) is the best to discuss this in case you have any questions. There is no doubt you can increase TCP state tracking as soon as you do window / sequence number tracking. But without, I don't see how you could do any better [in terms of security] than we do. You can represent the state more verbously - but without any practical implications for security, there is no other than academic interest in this. -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
