From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 72F8313826B for ; Thu, 3 Jan 2013 03:52:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8672121C04A; Thu, 3 Jan 2013 03:52:27 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E968721C027 for ; Thu, 3 Jan 2013 03:50:51 +0000 (UTC) Received: from mail-da0-f48.google.com ([209.85.210.48]:46063) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1TqbpT-001hVe-Jm for gentoo-user@lists.gentoo.org; Thu, 03 Jan 2013 10:50:51 +0700 Received: by mail-da0-f48.google.com with SMTP id k18so6757475dae.35 for ; Wed, 02 Jan 2013 19:50:50 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.68.227.41 with SMTP id rx9mr149203133pbc.121.1357185050159; Wed, 02 Jan 2013 19:50:50 -0800 (PST) Received: by 10.68.248.66 with HTTP; Wed, 2 Jan 2013 19:50:49 -0800 (PST) Received: by 10.68.248.66 with HTTP; Wed, 2 Jan 2013 19:50:49 -0800 (PST) In-Reply-To: <50E48222.5050509@orlitzky.com> References: <50E43853.20203@libertytrek.org> <50E48222.5050509@orlitzky.com> Date: Thu, 3 Jan 2013 10:50:49 +0700 Message-ID: Subject: Re: [gentoo-user] IPtables - Mangle table - when/why do I need it (or do I need it)? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=e89a8ff1ce76cf297004d25a4424 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Get-Message-Sender-Via: svr-us4.tirtonadi.com: authenticated_id: rileyer+pandu.poluan.info/only user confirmed/virtual account not confirmed X-Archives-Salt: 461c0302-a3a6-49b3-b08d-ac0d1af04f61 X-Archives-Hash: f244e598a2993cab75910665ccde6832 --e89a8ff1ce76cf297004d25a4424 Content-Type: text/plain; charset=UTF-8 On Jan 3, 2013 1:57 AM, "Michael Orlitzky" 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, -- --e89a8ff1ce76cf297004d25a4424 Content-Type: text/html; charset=UTF-8


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,
--

--e89a8ff1ce76cf297004d25a4424--