On Jan 3, 2013 1:57 AM, "Michael Orlitzky" <mich...@orlitzky.com> wrote: > > On 01/02/13 08:38, Tanstaafl wrote: > > Hi all, > > > > This has been bugging me for a while... > > > > I've googled, and can't seem to find a definitive answer to this > > question... > > > > Lots of references to the Mangle table, but nothing that really explains > > what this table is or does, and when or why I would want/need it. > > > > It allows you to mangle the low level bits of a packet. You only need it > for routing gymnastics. > > > > Currently, I have this in my rules (since forever, honestly don't even > > remember where it came from): > > > > *mangle > > :PREROUTING ACCEPT [1378800222:449528056411] > > :INPUT ACCEPT [1363738727:447358082301] > > :FORWARD ACCEPT [0:0] > > :OUTPUT ACCEPT [1221121261:1103241097263] > > :POSTROUTING ACCEPT [1221116979:1103240864155] > > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG > > FIN,PSH,URG -j DROP > > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j > > DROP > > -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP > > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP > > COMMIT > > # Completed on Sun Dec 11 14:11:01 2011 > > > > The PREROUTING table happens before the routing decision is made. So > those rules happen before the network stack decides what to do with a > packet. > > Suppose, for example, that you forward all packets from your LAN to > wherever they're supposed to go. You might want to alter the source IP > of VPN traffic (which a priori is not from the LAN interface) so that it > appears to come from the LAN before you decide whether or not to forward it. > > The POSTROUTING table is similar, only it happens after the packet's > destination is set in stone. So you can, say, change the source IP > address in the packet and still have it routed wherever it was going to > go originally. > > > > This is on a mail/web server with a static IP, it does not do any NAT > > and does not act as a perimeter firewall, it only protects itself... > > > > Thanks for any pointers to tfm that explains this if there is one, or > > just for a simple explanation if not... > > > > I don't know what you were trying to do there, but it doesn't sound like > you need it. You might have been trying to block packets in an invalid > state. If so, consider using conntrack's --ctstate INVALID to drop them > instead. >
Just to add some references... When dealing with iptables (and its kissing cousin, ebtables), I always find these diagrams to be most helpful: Definitive: http://www.wenzk.net/bbs/attachments/PacketFlow_BTgdX6im2Scu.png Complementary: http://linux-ip.net/nf/nfk-traversal.png Rgds, --
