On Monday 20 May 2002 16:02, Glover George wrote: > True, but I'm talking about only the INPUT, FORWARD, and OUTPUT > chains. Why would you need test data? There should be a way to > actually insert a packet into the real chains and see if it comes > out (some sort of hook to see if it's a test packet or something).
Because of the complexity of all the matches there is.. iptables is way beyond a "simple packet filter" such as ipchains. Sure, a simple test function can be made for simple rules only using basic TCP/IP tests, but what do you do if there is a match that depends on conntrack state, or even local socket state (user or application name matches)? Or other protocols than TCP/UDP/ICMP? In such case the test function will quite likely be of very limited value as it can only simulate a fraction of the information needed by your ruleset. > It seems to me that there could be widespread use of a way to more > automate the firewalling rules. Right now, it takes manual entry, > and most people are probably coming up with the best rules they > know and leaving them static for long periods of time. Wouldn't it > behove us to have more interoperability with the sub-system? > Things like testing a packet against a chain really seems to me > like a very useful thing, maybe not an easy thing, but nevertheless > a useful and acheivable thing. In all netfilter based firewalls the ability to test a single packet against the chain from the firewall itself hasn't been much of a value.. More of value is to make good use of logging to see why the ruleset decided to drop or allow a packet. The rule packet counts is also helpful when testing and debugging rulesets. Simulating packets form the outside is quite simple, and gives you a much better verdict on how your firewall decides to deal with the packet. Regards Henrik Nordström
