-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan, : The basic architecture of NetFilter is: : : --->[1]--->(ROUTE)--->[3]--->[4]---> where: : | ^ [1] NF_IP_PRE_ROUTING : | | [2] NF_IP_LOCAL_IN : | (ROUTE) [3] NF_IP_FORWARD : v | [4] NF_IP_POST_ROUTING : [2] [5] [5] NF_IP_LOCAL_OUT : | ^ : | | : v | : Q1: Is the diagram accurate? If not, what should it look like? Largely. This is a question answered often on this and other lists, and decent overviews can be found here [0], [1] and [2]. : The man page for iptables(8) lists these independent tables: : : filter, with builtin chains for INPUT, OUTPUT, and FORWARD; : : nat, with builtin chains for PREROUTING, OUTPUT, and : POSTROUTING; : : mangle, with builtin chains for PREROUTING, OUTPUT, INPUT, : FORWARD, and POSTROUTING; : : raw, with builtin chains for PREROUTING and OUTPUT. : : Q2: How do these tables and chains fit into the picture above? : Is it correct to say that each table represents a collection of : hooks, with each builtin chain inserted at the appropriate : NF_IP_* location? I, also, believe this to be true. (I am not a kernel developer). : Q3: If so, in what order are the hooks applied? For instance, : during NF_IP_LOCAL_IN processing which table comes first, filter : or mangle? See include/linux/netfilter_ipv4.h for enum nf_ip_hook_priorities. : Source NAT gets applied during NF_IP_POST_ROUTING. However, part : of Source NAT is to recognize packets whose destination IP : address and port correspond to an established NAT session and to : undo the translation. : Q4: Where does this "un-NAT" operation take place? Is it during : NF_IP_PRE_ROUTING? : : It can be important for firewall rules to know when they are dealing : with a packet which has undergone Destination NAT or Source "un-NAT" : processing. With Destination NAT, one possible way to tell would be : to set a firewall mark in packets before they are transformed. Connection tracking takes care of this for you. DNAT "un-NAT" occurs as close as possible to transmission time. SNAT "un-NAT" occurs as close as possible to reception. This is consistent with the desire to keep decesions for firewalling and routing as clear as possible to the most-logical view of packet processing on the L3 device in question. For further explanation of why, consider Michael Hasenstein's (venerable, by now) paper on NAT, specifically as used for network addressing virtualization [3]. : Q5: Does Destination NAT processing maintain a packet's existing : firewall mark? Metadata (e.g., nfmarks) added to the packet during processing are retained through network address translation, yes. : Q6: With Source "un-NAT" there doesn't seem to be any way to mark : a packet as having been transformed. Is it possible to do : anything better than test whether the packet would have met the : Source NAT criteria if it had been sent in the opposite : direction? Perhaps you are looking for the 'conntrack' module to iptables? I would think that you'd be able to extract the data you wish with - --ctorigdst or --ctorigsrc [4]. : Moving on to IPsec... And, I can't help you with the IPSec questions. Good luck, - -Martin [0] http://linux-ip.net/nf/nfk-traversal.pdf [1] http://open-source.arkoon.net/kernel/kernel_net.png [2] http://www.docum.org/docum.org/kptd/ [3] http://www.hasenstein.com/linux-ip-nat/diplom/ [4] $ iptables -m conntrack --help | tail -18 conntrack match v1.3.3 options: [!] --ctstate [INVALID|ESTABLISHED|NEW|RELATED|UNTRACKED|SNAT|DNAT][,...] State(s) to match [!] --ctproto proto Protocol to match; by number or name, eg. `tcp' --ctorigsrc [!] address[/mask] Original source specification --ctorigdst [!] address[/mask] Original destination specification --ctreplsrc [!] address[/mask] Reply source specification --ctrepldst [!] address[/mask] Reply destination specification [!] --ctstatus [NONE|EXPECTED|SEEN_REPLY|ASSURED|CONFIRMED][,...] Status(es) to match [!] --ctexpire time[:time] Match remaining lifetime in seconds against value or range of values (inclusive) - -- Martin A. Brown http://linux-ip.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFGPlWBHEoZD1iZ+YcRAijNAKC5cw1D3HV0FVaElZNu7FiKyE5CjgCeKDoh wUN005+ixRHT7fBs9q56pHo= =fKlq -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
