I've got several questions about the way the kernel implements NAT,
the rest of Netfilter, and IPsec, and the relationships among them.
These matters aren't explained in any of the documentation I've been
able to come across.
To set the stage, here's a diagram showing the basic outline of how
Netfilter fits into the IP stack. It was taken from a email message
written by Richard Guy Briggs:
====================================================================
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 |
The basic path through the kernel as it concerns IPSEC for the three
types of packets is as follows:
IN:
NIC
sanity check
NF_IP_PRE_ROUTING
route-in
ip-options processing
defragment
NF_IP_LOCAL_IN
layer3demux
application
FORWARD:
NIC
sanity check
NF_IP_PRE_ROUTING
routing-in
ip-options processing
ttl decrement and check
NF_IP_FORWARD
fragment
NF_IP_POST_ROUTING
output()
NIC
OUT:
application
layer3mux
NF_IP_LOCAL_OUT
route-out
NF_IP_POST_ROUTING
output()
NIC
Destination NAT (port forwarding) gets applied in NF_IP_PRE_ROUTING,
NF_IP_LOCAL_OUT and Source NAT (masquerading) gets applied in
NF_IP_POST_ROUTING. Filtering is applied in NF_IP_LOCAL_IN,
NF_IP_FORWARD and NF_IP_LOCAL_OUT.
====================================================================
Q1: Is the diagram accurate? If not, what should it look like?
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?
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?
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.
Q5: Does Destination NAT processing maintain a packet's existing
firewall mark?
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?
Moving on to IPsec...
Q7: Where do the IPsec operations fit into the picture?
Q8: Do they get applied before or after the various NAT
transformations?
Q9: How can filter rules tell whether they are dealing with a packet
which has been de-encapsulated from inside an IPsec wrapper?
In RFC 2401 (Security Architecture for the Internet Protocol), section 5
includes this text:
As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
the SPD must be consulted during the processing of all traffic
(INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is
found in the SPD that matches the packet (for either inbound or
outbound traffic), the packet MUST be discarded.
But on Linux systems, by default the SPD is normally empty and all
packets are allowed to pass unhindered.
Q10: Isn't this a violation of the RFC?
Thanks for any answers. I may think up more questions later...
Alan Stern
-
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
