On Thursday 09 January 2003 05:54 pm, Tony Clayton wrote: > I've been reading the various docs linked to from netfilter.org, > hoping to figure out the exact order in which a packet traverses the > various tables and chains as it passes through the network stack. > > Unfortunately, I couldn't find a definative resource that contained > this information, so I decided to figure it out myself. Oskar's tutorial at http://iptables-tutorial.frozentux.net covers it pretty nicely, although his main diagrams and tables don't clarify the single-hit nature of the NAT chains. (he covers this elsewhere) > I build a quick script to insert LOG rules into every chain of every > table, so that I could log the order in which the tables and chains > are traversed. That's the best solution anyway. Until you do it yourself you can't /really/ know it, and IIRC some earlier versions traversals were slightly different. (All through my childhood my mom had a sign in one room "I hear and I forget, I see and I remember, I do and I understand" which seems pretty accurate usually :^) > Here are my findings, using the three test cases below: [snipped] > This is quite interesting, and not at all what I was expecting based > on what I'd read. One you missed, which threw me when I first discovered it: Firewall box to itself. This one bypasses nat PREROUTING entirely... I guess since it's inbound on interface lo then there is only one rational destination anyway, so that chain would be pretty much useless. If you want to DNAT a localhost connection you do it in nat OUTPUT. > I have a list of questions about this behaviour, keeping in mind that > I'm fairly new to iptables/netfilter: > > 1. Why does only the first packet for a TCP/IP connection seem to pass > through the nat table? Does connection tracking take over if the > packet is (ESTABLISHED,RELATED) and work some magic under the covers? Precisely, plus some. Even if you don't have an 'EST/REL' rule, conntrack's still there under the hood. (check "lsmod | grep ip" and you'll see that ip_conntrack is a dependancy for iptable_nat) This is how netfilter knows that return traffic IS return traffic, and what IP to forward it back to when unSNATting packets. > 2. Why do both OUTPUT and POSTROUTING chains get traversed for packets > that the firewall sends out? Is this useful at all? As an example, you can DNAT in nat OUTPUT, (but not POSTROUTING - the routing decision has already been made) to allow you to change destination without the local process knowing or needing to know. You can SNAT in nat POSTROUTING but not OUTPUT. You can change TTL in mangle POSTROUTING for all packets, whether OUTPUT or FORWARD fed them in, so that for example they are all the same, (a few ISP's apparently look for differing TTL's when policing for 'hidden' machines that they want to charge connection fees for) and you can change TOS or mark in mangle OUTPUT so that routing can be based on those, which again has already been decided before the packet reaches any POSTROUTING chains. > 3. Most of the documents I looked at were fairly old. Is there a > somewhat recent document that perhaps might benefit from including > these tests? Oskar Andreasson's tutorial is updated and tweaked frequently, I believe he announced the latest update on this list Dec 19. The only references I've EVER used for iptables are his tutorial and the main documentation. He also recommends setting up log rules the way you did to double-check that traversal works the way you believe it does. > thanks, > > Tony j
