X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@mail.alpinelinux.org
Received: from jeremythomerson.com (mail.jeremythomerson.com [74.117.189.150])
	by mail.alpinelinux.org (Postfix) with ESMTP id 7CE97DC1262
	for <alpine-devel@lists.alpinelinux.org>; Tue, 25 Sep 2012 17:35:15 +0000 (UTC)
Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54])
	by jeremythomerson.com (Postfix) with ESMTP id 770761CA9C
	for <alpine-devel@lists.alpinelinux.org>; Tue, 25 Sep 2012 12:38:08 -0500 (CDT)
Received: by padbi1 with SMTP id bi1so2617946pad.13
        for <alpine-devel@lists.alpinelinux.org>; Tue, 25 Sep 2012 10:35:14 -0700 (PDT)
Received: by 10.68.242.231 with SMTP id wt7mr47686411pbc.99.1348594514049;
 Tue, 25 Sep 2012 10:35:14 -0700 (PDT)
X-Mailinglist: alpine-devel
Precedence: list
List-Id: Alpine Development <alpine-devel.lists.alpinelinux.org>
List-Unsubscribe: 
	<mailto:alpine-devel+unsubscribe@lists.alpinelinux.org?subject=unsubscribe>
List-Post: <mailto:alpine-devel@lists.alpinelinux.org>
List-Help: <mailto:alpine-devel+help@lists.alpinelinux.org?subject=help>
List-Subscribe: 
	<mailto:alpine-devel+subscribe@lists.alpinelinux.org?subject=subscribe>
MIME-Version: 1.0
Reply-To: jeremy@thomersonfamily.com
Received: by 10.66.14.229 with HTTP; Tue, 25 Sep 2012 10:34:53 -0700 (PDT)
From: Jeremy Thomerson <jeremy@thomersonfamily.com>
Date: Tue, 25 Sep 2012 12:34:53 -0500
Message-ID: <CADVmKVB+6-FzXoX-t8jxgOjpCRN4Dv=xeX8vYvqjw1jsi8kRRg@mail.gmail.com>
Subject: [alpine-devel] awall - forward to/from same port
To: Alpine-devel <alpine-devel@lists.alpinelinux.org>
Content-Type: multipart/alternative; boundary=047d7b339c83f4ba8804ca8a201b

--047d7b339c83f4ba8804ca8a201b
Content-Type: text/plain; charset=ISO-8859-1

I have a GRE device on my firewall, which is acting as an OpenNHRP core.
 If two OpenNHRP nodes are trying to talk to each other and unable to
establish a direct connection they send their traffic through the core.
 This means that from iptables standpoint the traffic is coming from gre1
and going to gre1.

I use awall to generate the iptables rules on this FW.  It all works fine
so far except for this.  Traffic from one node to another that was passing
through my core was getting blocked with this in the syslog:

Sep 25 17:26:39 jrt-vm-fw01 kern.warn kernel: [918524.175624] IN=gre1
OUT=gre1 MAC= SRC=172.23.0.3 DST=172.23.0.2 LEN=84 TOS=0x00 PREC=0x00
TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=36686 SEQ=16

So, I tried adding this to my awall config:

                {
                "in": "T",
                "out": "T",
                "action": "accept"
                }

The problem is that awall didn't create a rule in the forward chain for -i
gre1 -o gre1.  So, traffic continued getting blocked.  When I added the
following rule manually in /etc/iptables/rules-save (just before the
forward chain's LOGDROP) it worked fine:

-A FORWARD -i gre1 -o gre1 -j ACCEPT

Is this a bug in awall that it assumes you don't need a forward chain rule
if the input and output devices are the same?

Jeremy Thomerson

--047d7b339c83f4ba8804ca8a201b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have a GRE device on my firewall, which is acting as an OpenNHRP core. =
=A0If two OpenNHRP nodes are trying to talk to each other and unable to est=
ablish a direct connection they send their traffic through the core. =A0Thi=
s means that from iptables standpoint the traffic is coming from gre1 and g=
oing to gre1.<div>

<br></div><div>I use awall to generate the iptables rules on this FW. =A0It=
 all works fine so far except for this. =A0Traffic from one node to another=
 that was passing through my core was getting blocked with this in the sysl=
og:=A0</div>

<div><br></div><div><div>Sep 25 17:26:39 jrt-vm-fw01 kern.warn kernel: [918=
524.175624] IN=3Dgre1 OUT=3Dgre1 MAC=3D SRC=3D172.23.0.3 DST=3D172.23.0.2 L=
EN=3D84 TOS=3D0x00 PREC=3D0x00 TTL=3D63 ID=3D0 DF PROTO=3DICMP TYPE=3D8 COD=
E=3D0 ID=3D36686 SEQ=3D16=A0</div>

</div><div><br></div><div>So, I tried adding this to my awall config:</div>=
<div><br></div><div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {</div><div>=A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <span class=3D"Apple-tab-span" style=3D"white-s=
pace:pre">	</span>&quot;in&quot;: &quot;T&quot;,</div>

<div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <span class=3D"Apple-tab-span" style=
=3D"white-space:pre">	</span>&quot;out&quot;: &quot;T&quot;,</div><div>=A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <span class=3D"Apple-tab-span" style=3D"white-s=
pace:pre">	</span>&quot;action&quot;: &quot;accept&quot;</div>

<div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }</div></div><div><br></div><div>The p=
roblem is that awall didn&#39;t create a rule in the forward chain for -i g=
re1 -o gre1. =A0So, traffic continued getting blocked. =A0When I added the =
following rule manually in /etc/iptables/rules-save (just before the forwar=
d chain&#39;s LOGDROP) it worked fine:</div>

<div><br></div><div>-A FORWARD -i gre1 -o gre1 -j ACCEPT</div><div><br></di=
v><div>Is this a bug in awall that it assumes you don&#39;t need a forward =
chain rule if the input and output devices are the same?</div><div><br>

</div><div>Jeremy Thomerson</div>

--047d7b339c83f4ba8804ca8a201b--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---