"n/a" <[EMAIL PROTECTED]> writes: > > Apparently there's something i'm not getting thru my thick skull about > packet filtering.
I think others have pointed out the main problem---packets being forwarded by the machine don't pass through the INPUT and OUTPUT chains. This behaviour differs from the old "ipchains" behaviour: see iptables(8), the section titled "COMPATIBILITY WITH IPCHAINS". If you're trying to build your tables based on old "ipchains" examples, you'll run into trouble. > Could someone explain to me in text (no diagrams) how a > packet is evaluated and then processed tru the chains, also what is done and > not-done any more after a packet has passed thru a chain. There's a good explanation in the Netfilter Hacking HOWTO: http://www.netfilter.org/documentation/HOWTO//netfilter-hacking-HOWTO.html though it uses a couple of ASCII diagrams. In a nutshell, the kernel networking code includes several netfilter "hooks" where packets can be examined, dropped, modified, rerouted, or whatever. An IP packet arriving on any interface (even the loopback interface) is first passed to the NF_IP_PRE_ROUTING hook. This happens even before the kernel decides whether the packet is destined for a local process or needs to be forwarded to another machine. Next, the packet enters the kernel routing code which decides what to do with it. Packets directed at a local IP address pass through the NF_IP_LOCAL_IN hook. After this, they are dealt with by the kernel in the "usual" manner (including passing the data up to an appropriate user process). Packets that must be forwarded don't pass through this hook. Instead, they pass through the NF_IP_FORWARD hook, then through the NF_IP_POST_ROUTING hook, and then to the appropriate device driver. Locally generated packets are handled first by the routing code before being passed to the NF_IP_LOCAL_OUT hook (which can change their routing) and then the NF_IP_POST_ROUTING hook, and then to the appropriate device. The upshot is this: Packets arriving from a different machine and directed at one of the firewall's IP addresses pass through the NF_IP_PRE_ROUTING and NF_IP_LOCAL_IN hooks. Packets arriving from a different machine that must be forwarded to another machine pass through the NF_IP_PRE_ROUTING, the NF_IP_FORWARD, and the NF_IP_POST_ROUTING hooks. Locally generated packets destined for another machine pass through the NF_IP_LOCAL_OUT and NF_IP_POST_ROUTING hooks. Packets sent from the firewall back into the firewall (e.g., "telnet localhost") pass out through the NF_IP_LOCAL_OUT and NF_IP_POST_ROUTING hooks and then back in through the NF_IP_PRE_ROUTING and NF_IP_LOCAL_IN hooks. That's all assuming that none of the hooks interfere with the packet. Since the hooks can drop, modify, or otherwise reroute the packet, the actual path of a packet can be even more complicated. The hooks can do all sorts of things. One of the main things they do is apply the rules that you set with "iptables". If the only table you configure is the "filter" table, its three chains INPUT, OUTPUT, and FORWARD, will be applied at the LOCAL_IN, LOCAL_OUT, and FORWARD hooks. Therefore, packets will only pass through one of the three filter chains (except packets through the loopback which are processed by the OUTPUT chain on the way out and the INPUT chain on the way in). In your case, it looks like you need to do some masquerading for your internal LAN, so things get a bit more complicated. If you configure the "nat" table, too, destination NAT (i.e., changing the destination of a packet) in the "nat" PREROUTING chain is applied in the PRE_ROUTING hook: a packet arriving from the big, bad Internet that *seems* to be for the firewall's external IP address could be *really* for the firewall or it might be for a machine on the internal LAN. The destination NAT is applied at the PRE_ROUTING stage so that it can rewrite the destination address before the kernel routing code makes its decision. Then, it gets passed to LOCAL_IN or FORWARD as appropriate. (Destination NAT can also be applied via the "nat" OUTPUT chain in the OUTPUT hook if you want to redirect locally generated packets for some reason; and source NAT is applied via the "nat" POSTROUTING chain in the POST_ROUTING hook after the packet has already passed through the "filter" OUTPUT or FORWARD chains.) I hope that helps. I can't tell from the configuration rules you gave exactly what it is you're trying to do. It looks like you want internal hosts to be able to make direct SMTP and POP connections to a certain subnet of external hosts and web connections to "kottweb", but you want to prevent all other connections (except web connections proxied through the firewall). Can you clarify this? -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
