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