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

From: Jeremy Thomerson <[email-masked]>
Date: Tue, 25 Sep 2012 12:34:53 -0500

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

---

From: Natanael Copa <[email-masked]>
Date: Wed, 26 Sep 2012 09:07:49 +0200

On Tue, 25 Sep 2012 12:34:53 -0500
Jeremy Thomerson <[email-masked]> wrote:

> This means that from iptables standpoint the
> traffic is coming from gre1 and going to gre1.
... 
> 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:  [email-masked]
Help:         [email-masked]
---

---

From: Kaarle Ritvanen <[email-masked]>
Date: Wed, 26 Sep 2012 17:10:13 +0300 (EEST)

> 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

---

---

From: Jeremy Thomerson <[email-masked]>
Date: Wed, 26 Sep 2012 09:32:43 -0500

On Wed, Sep 26, 2012 at 9:10 AM, Kaarle Ritvanen <
[email-masked]> wrote:

> 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"
                }

---

From: Natanael Copa <[email-masked]>
Date: Thu, 27 Sep 2012 10:13:14 +0200

On Wed, 26 Sep 2012 17:10:13 +0300 (EEST)
Kaarle Ritvanen <[email-masked]> wrote:

> > Not that it means that awall should do the same, but in shorewall
> > you add an option called "routeback" to the interface definition.
> 
> 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

---

---

From: Kaarle Ritvanen <[email-masked]>
Date: Wed, 3 Oct 2012 10:52:17 +0300 (EEST)

> 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

---

---

From: Jeremy Thomerson <[email-masked]>
Date: Wed, 3 Oct 2012 10:39:22 -0500

On Wed, Oct 3, 2012 at 2:52 AM, Kaarle Ritvanen <
[email-masked]> wrote:

>> Kaarle Ritvanen <[email-masked]**> wrote:
>>
> this does not as such allow any traffic, but just allows the filter rule to
> produce iptables rules with identical ingress and egress interfaces.
>

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

---

From: Leonardo <[email-masked]>
Date: Thu, 04 Oct 2012 08:27:59 +0200

On Wed, 2012-10-03 at 10:39 -0500, Jeremy Thomerson wrote:
> 
> On Wed, Oct 3, 2012 at 2:52 AM, Kaarle Ritvanen
> <[email-masked]> wrote:
>         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.
>         
> 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

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