On Jan 3, 2013 1:57 AM, "Michael Orlitzky" <michael@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,
--