~alpine/devel

7 4

[alpine-devel] awall - forward to/from same port

Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<CADVmKVB+6-FzXoX-t8jxgOjpCRN4Dv=xeX8vYvqjw1jsi8kRRg@mail.gmail.com>
Sender timestamp
1348594493
DKIM signature
missing
Download raw message
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
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20120926090749.4523d331@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<CADVmKVB+6-FzXoX-t8jxgOjpCRN4Dv=xeX8vYvqjw1jsi8kRRg@mail.gmail.com> (view parent)
Sender timestamp
1348643269
DKIM signature
missing
Download raw message
On Tue, 25 Sep 2012 12:34:53 -0500
Jeremy Thomerson <jeremy@thomersonfamily.com> wrote:

> This means that from iptables standpoint the
> traffic is coming from gre1 and going to gre1.
... 
> 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.

Not that it means that awall should do the same, but in shorewall you
add an option called "routeback" to the interface definition.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<CADVmKVAG6S_qHJKPw4GLie7HeJDmSH-_kw7qNxKiKEcX9+LK8A@mail.gmail.com>
In-Reply-To
<alpine.LFD.2.02.1209261704360.5933@kunkku.net> (view parent)
Sender timestamp
1348669963
DKIM signature
missing
Download raw message
On Wed, Sep 26, 2012 at 9:10 AM, Kaarle Ritvanen <
kaarle.ritvanen@datakunkku.fi> wrote:

> On Wed, 26 Sep 2012, Natanael Copa wrote:
>
>  On Tue, 25 Sep 2012 12:34:53 -0500
>> Jeremy Thomerson <jeremy@thomersonfamily.com> wrote:
>>
>>> The problem is that awall didn't create a rule in the forward chain
>>> for -i gre1 -o gre1.
>>>
>>
>> Not that it means that awall should do the same, but in shorewall you
>> add an option called "routeback" to the interface definition.
>>
>
> Well, we could add similar attribute to zone definitions or just make
> awall always generate such rules. The downside of the latter option is that
> those rules are likely unnecessary in most cases, causing a slight penalty
> in performance. What do you think?
>

Perhaps we could add the attribute to the filter definition instead.  i.e.:

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

OR:

                {
                        "in": "T",
                        "out": "T",
                        "action": "acceptandrouteback"
                }
Details
Message ID
<alpine.LFD.2.02.1209261704360.5933@kunkku.net>
In-Reply-To
<20120926090749.4523d331@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1348668613
DKIM signature
missing
Download raw message
On Wed, 26 Sep 2012, Natanael Copa wrote:

> On Tue, 25 Sep 2012 12:34:53 -0500
> Jeremy Thomerson <jeremy@thomersonfamily.com> wrote:
>> The problem is that awall didn't create a rule in the forward chain
>> for -i gre1 -o gre1.
>
> Not that it means that awall should do the same, but in shorewall you
> add an option called "routeback" to the interface definition.

Well, we could add similar attribute to zone definitions or just make 
awall always generate such rules. The downside of the latter option is 
that those rules are likely unnecessary in most cases, causing a slight 
penalty in performance. What do you think?

BR,
Kaarle


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20120927101314.65e3bcf1@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<alpine.LFD.2.02.1209261704360.5933@kunkku.net> (view parent)
Sender timestamp
1348733594
DKIM signature
missing
Download raw message
On Wed, 26 Sep 2012 17:10:13 +0300 (EEST)
Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi> wrote:

> On Wed, 26 Sep 2012, Natanael Copa wrote:
> 
> > On Tue, 25 Sep 2012 12:34:53 -0500
> > Jeremy Thomerson <jeremy@thomersonfamily.com> wrote:
> >> The problem is that awall didn't create a rule in the forward chain
> >> for -i gre1 -o gre1.
> >
> > Not that it means that awall should do the same, but in shorewall
> > you add an option called "routeback" to the interface definition.
> 
> Well, we could add similar attribute to zone definitions or just make 
> awall always generate such rules. The downside of the latter option
> is that those rules are likely unnecessary in most cases, causing a
> slight penalty in performance. What do you think?

Always generate such rules? No, I'd prefer it be optional and default
off.

Re adding the feature to filter section vs zone definition, I suppose
the benefit with adding it to zone definition is that it would be
slightly easier to make scripts that ports shorewall config to awall.

Would it be possible to support both? So you can do both

"zone": { "T": { "iface": "gre1", "routeback": "true" } }

or: 

"zone": { "T": { "iface": "gre1", "options": [ "routeback" ] } }

and:

"filter": [
  { "in": "T", "out": "T", "action": "accept" }
]

As I understand the latter currently don't work.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jeremy Thomerson <jeremy@thomersonfamily.com>
Details
Message ID
<CADVmKVAB7Y565+YworL_mpiwwHNUb3wcaME1eDWLiPNe01JFmA@mail.gmail.com>
In-Reply-To
<alpine.LFD.2.02.1210031044220.23327@kunkku.net> (view parent)
Sender timestamp
1349278762
DKIM signature
missing
Download raw message
On Wed, Oct 3, 2012 at 2:52 AM, Kaarle Ritvanen <
kaarle.ritvanen@datakunkku.fi> wrote:

> On Thu, 27 Sep 2012, Natanael Copa wrote:
>
>  On Wed, 26 Sep 2012 17:10:13 +0300 (EEST)
>> Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi**> wrote:
>>
>>  Well, we could add similar attribute to zone definitions or just make
>>> awall always generate such rules. The downside of the latter option
>>> is that those rules are likely unnecessary in most cases, causing a
>>> slight penalty in performance. What do you think?
>>>
>>
>> Always generate such rules? No, I'd prefer it be optional and default
>> off.
>>
>> Re adding the feature to filter section vs zone definition, I suppose
>> the benefit with adding it to zone definition is that it would be
>> slightly easier to make scripts that ports shorewall config to awall.
>>
>
> I added an optional 'route-back' attribute to zone definitions. Note that
> this does not as such allow any traffic, but just allows the filter rule to
> produce iptables rules with identical ingress and egress interfaces.
>
> This feature is available in version 0.2.11.
>

Thanks Kaarle!  That worked great.  I do have a question.  Do you have a
plan to update http://wiki.alpinelinux.org/wiki/How-To_Alpine_Wall to show
the new logging stuff?  My "logdrop" and "logreject" are now deprecated,
and I found on http://wiki.alpinelinux.org/wiki/Alpine_Wall_User%27s_Guidethat
there is a different way of configuring this now.  But that makes the
first link above out of date.  I'm wondering if we should consolidate that
first page into the second so it's more likely to stay up-to-date.

Thanks again,
Jeremy Thomerson
Details
Message ID
<alpine.LFD.2.02.1210031044220.23327@kunkku.net>
In-Reply-To
<20120927101314.65e3bcf1@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1349250737
DKIM signature
missing
Download raw message
On Thu, 27 Sep 2012, Natanael Copa wrote:

> On Wed, 26 Sep 2012 17:10:13 +0300 (EEST)
> Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi> wrote:
>
>> Well, we could add similar attribute to zone definitions or just make
>> awall always generate such rules. The downside of the latter option
>> is that those rules are likely unnecessary in most cases, causing a
>> slight penalty in performance. What do you think?
>
> Always generate such rules? No, I'd prefer it be optional and default
> off.
>
> Re adding the feature to filter section vs zone definition, I suppose
> the benefit with adding it to zone definition is that it would be
> slightly easier to make scripts that ports shorewall config to awall.

I added an optional 'route-back' attribute to zone definitions. Note that 
this does not as such allow any traffic, but just allows the filter rule 
to produce iptables rules with identical ingress and egress interfaces.

This feature is available in version 0.2.11.

BR,
Kaarle


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<1349332079.11942.35.camel@df1844j>
In-Reply-To
<CADVmKVAB7Y565+YworL_mpiwwHNUb3wcaME1eDWLiPNe01JFmA@mail.gmail.com> (view parent)
Sender timestamp
1349332079
DKIM signature
missing
Download raw message
On Wed, 2012-10-03 at 10:39 -0500, Jeremy Thomerson wrote:
> 
> On Wed, Oct 3, 2012 at 2:52 AM, Kaarle Ritvanen
> <kaarle.ritvanen@datakunkku.fi> wrote:
>         On Thu, 27 Sep 2012, Natanael Copa wrote:
>         
>         
>                 On Wed, 26 Sep 2012 17:10:13 +0300 (EEST)
>                 Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi> wrote:
>                 
>                 
>                         Well, we could add similar attribute to zone
>                         definitions or just make
>                         awall always generate such rules. The downside
>                         of the latter option
>                         is that those rules are likely unnecessary in
>                         most cases, causing a
>                         slight penalty in performance. What do you
>                         think?
>                 
>                 Always generate such rules? No, I'd prefer it be
>                 optional and default
>                 off.
>                 
>                 Re adding the feature to filter section vs zone
>                 definition, I suppose
>                 the benefit with adding it to zone definition is that
>                 it would be
>                 slightly easier to make scripts that ports shorewall
>                 config to awall.
>                 
>         
>         I added an optional 'route-back' attribute to zone
>         definitions. Note that this does not as such allow any
>         traffic, but just allows the filter rule to produce iptables
>         rules with identical ingress and egress interfaces.
>         
>         This feature is available in version 0.2.11.
> 
> Thanks Kaarle!  That worked great.  I do have a question.  Do you have
> a plan to update http://wiki.alpinelinux.org/wiki/How-To_Alpine_Wall
> to show the new logging stuff?  My "logdrop" and "logreject" are now
> deprecated, and I found on
> http://wiki.alpinelinux.org/wiki/Alpine_Wall_User%27s_Guide that there
> is a different way of configuring this now.  But that makes the first
> link above out of date.  I'm wondering if we should consolidate that
> first page into the second so it's more likely to stay up-to-date.

That's me who wrote that page. Yeah, I'm supposed to update that page as
soon as I have some time. The idea was that the User Guide it's just a
"guide" explaining every possibility offered by AWall. While the How-To
it's more a Shorewall->AWall migration how-to document.

Thanks for the reminder!

- leonardo
Reply to thread Export thread (mbox)