Gentoo Archives: gentoo-user

From: Pandu Poluan <pandu@××××××.info>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] IPtables - Mangle table - when/why do I need it (or do I need it)?
Date: Thu, 03 Jan 2013 03:52:41
Message-Id: CAA2qdGVFPyiAR0ACBSxQXMj4Z8rp7S0ykHFi5TmOM1+4pejXEA@mail.gmail.com
In Reply to: Re: [gentoo-user] IPtables - Mangle table - when/why do I need it (or do I need it)? by Michael Orlitzky
1 On Jan 3, 2013 1:57 AM, "Michael Orlitzky" <michael@××××××××.com> wrote:
2 >
3 > On 01/02/13 08:38, Tanstaafl wrote:
4 > > Hi all,
5 > >
6 > > This has been bugging me for a while...
7 > >
8 > > I've googled, and can't seem to find a definitive answer to this
9 > > question...
10 > >
11 > > Lots of references to the Mangle table, but nothing that really explains
12 > > what this table is or does, and when or why I would want/need it.
13 > >
14 >
15 > It allows you to mangle the low level bits of a packet. You only need it
16 > for routing gymnastics.
17 >
18 >
19 > > Currently, I have this in my rules (since forever, honestly don't even
20 > > remember where it came from):
21 > >
22 > > *mangle
23 > > :PREROUTING ACCEPT [1378800222:449528056411]
24 > > :INPUT ACCEPT [1363738727:447358082301]
25 > > :FORWARD ACCEPT [0:0]
26 > > :OUTPUT ACCEPT [1221121261:1103241097263]
27 > > :POSTROUTING ACCEPT [1221116979:1103240864155]
28 > > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG
29 > > FIN,PSH,URG -j DROP
30 > > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j
31 > > DROP
32 > > -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
33 > > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
34 > > COMMIT
35 > > # Completed on Sun Dec 11 14:11:01 2011
36 > >
37 >
38 > The PREROUTING table happens before the routing decision is made. So
39 > those rules happen before the network stack decides what to do with a
40 > packet.
41 >
42 > Suppose, for example, that you forward all packets from your LAN to
43 > wherever they're supposed to go. You might want to alter the source IP
44 > of VPN traffic (which a priori is not from the LAN interface) so that it
45 > appears to come from the LAN before you decide whether or not to forward
46 it.
47 >
48 > The POSTROUTING table is similar, only it happens after the packet's
49 > destination is set in stone. So you can, say, change the source IP
50 > address in the packet and still have it routed wherever it was going to
51 > go originally.
52 >
53 >
54 > > This is on a mail/web server with a static IP, it does not do any NAT
55 > > and does not act as a perimeter firewall, it only protects itself...
56 > >
57 > > Thanks for any pointers to tfm that explains this if there is one, or
58 > > just for a simple explanation if not...
59 > >
60 >
61 > I don't know what you were trying to do there, but it doesn't sound like
62 > you need it. You might have been trying to block packets in an invalid
63 > state. If so, consider using conntrack's --ctstate INVALID to drop them
64 > instead.
65 >
66
67 Just to add some references...
68
69 When dealing with iptables (and its kissing cousin, ebtables), I always
70 find these diagrams to be most helpful:
71
72 Definitive: http://www.wenzk.net/bbs/attachments/PacketFlow_BTgdX6im2Scu.png
73
74 Complementary: http://linux-ip.net/nf/nfk-traversal.png
75
76 Rgds,
77 --