From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-144126-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 72F8313826B
for <garchives@archives.gentoo.org>; 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 <gentoo-user@lists.gentoo.org>; 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 <pandu@poluan.info>)
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 <gentoo-user@lists.gentoo.org>; Wed, 02 Jan 2013 19:50:50 -0800 (PST)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
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: <CAA2qdGVFPyiAR0ACBSxQXMj4Z8rp7S0ykHFi5TmOM1+4pejXEA@mail.gmail.com>
Subject: Re: [gentoo-user] IPtables - Mangle table - when/why do I need it (or
do I need it)?
From: Pandu Poluan <pandu@poluan.info>
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" <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
Content-Type: text/html; charset=UTF-8
<p><br>
On Jan 3, 2013 1:57 AM, "Michael Orlitzky" <<a href="mailto:michael@orlitzky.com">michael@orlitzky.com</a>> wrote:<br>
><br>
> On 01/02/13 08:38, Tanstaafl wrote:<br>
> > Hi all,<br>
> ><br>
> > This has been bugging me for a while...<br>
> ><br>
> > I've googled, and can't seem to find a definitive answer to this<br>
> > question...<br>
> ><br>
> > Lots of references to the Mangle table, but nothing that really explains<br>
> > what this table is or does, and when or why I would want/need it.<br>
> ><br>
><br>
> It allows you to mangle the low level bits of a packet. You only need it<br>
> for routing gymnastics.<br>
><br>
><br>
> > Currently, I have this in my rules (since forever, honestly don't even<br>
> > remember where it came from):<br>
> ><br>
> > *mangle<br>
> > :PREROUTING ACCEPT [1378800222:449528056411]<br>
> > :INPUT ACCEPT [1363738727:447358082301]<br>
> > :FORWARD ACCEPT [0:0]<br>
> > :OUTPUT ACCEPT [1221121261:1103241097263]<br>
> > :POSTROUTING ACCEPT [1221116979:1103240864155]<br>
> > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG<br>
> > FIN,PSH,URG -j DROP<br>
> > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j<br>
> > DROP<br>
> > -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP<br>
> > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP<br>
> > COMMIT<br>
> > # Completed on Sun Dec 11 14:11:01 2011<br>
> ><br>
><br>
> The PREROUTING table happens before the routing decision is made. So<br>
> those rules happen before the network stack decides what to do with a<br>
> packet.<br>
><br>
> Suppose, for example, that you forward all packets from your LAN to<br>
> wherever they're supposed to go. You might want to alter the source IP<br>
> of VPN traffic (which a priori is not from the LAN interface) so that it<br>
> appears to come from the LAN before you decide whether or not to forward it.<br>
><br>
> The POSTROUTING table is similar, only it happens after the packet's<br>
> destination is set in stone. So you can, say, change the source IP<br>
> address in the packet and still have it routed wherever it was going to<br>
> go originally.<br>
><br>
><br>
> > This is on a mail/web server with a static IP, it does not do any NAT<br>
> > and does not act as a perimeter firewall, it only protects itself...<br>
> ><br>
> > Thanks for any pointers to tfm that explains this if there is one, or<br>
> > just for a simple explanation if not...<br>
> ><br>
><br>
> I don't know what you were trying to do there, but it doesn't sound like<br>
> you need it. You might have been trying to block packets in an invalid<br>
> state. If so, consider using conntrack's --ctstate INVALID to drop them<br>
> instead.<br>
></p>
<p>Just to add some references... </p>
<p>When dealing with iptables (and its kissing cousin, ebtables), I always find these diagrams to be most helpful:</p>
<p>Definitive: <a href="http://www.wenzk.net/bbs/attachments/PacketFlow_BTgdX6im2Scu.png">http://www.wenzk.net/bbs/attachments/PacketFlow_BTgdX6im2Scu.png</a></p>
<p>Complementary: <a href="http://linux-ip.net/nf/nfk-traversal.png">http://linux-ip.net/nf/nfk-traversal.png</a></p>
<p>Rgds, <br>
--<br>
</p>
--e89a8ff1ce76cf297004d25a4424--