[Ferm] Parser error or user error ...

[Bret Giddings]

HI Auke,

On 31 December 2015 at 20:47, Auke Kok <sofar at foo-projects.org> wrote:
>
>
> On 12/31/2015 04:15 AM, Bret Giddings wrote:
>>
>> Hello,
>>
>> The following (somewhat contrived) snippet results in a warning message of
>>
>> Warning in test.ferm line 16: Chain is already specified
>>
>> table filter {
>>      chain FORWARD {
>>          policy DROP;
>>          # connection tracking
>>          mod state state INVALID DROP;
>>          mod state state (ESTABLISHED RELATED) ACCEPT;
>>
>>          interface eth0 outerface eth1 @subchain eth0.eth1 {
>>                  chain dns {
>>                          daddr 1.2.3.4 ACCEPT;
>>                          daddr 5.6.7.8 ACCEPT;
>>                  }
>>                  protocol (udp tcp) dport 53 realgoto dns;
>>          }
>>      }
>> }
>>
>> This appears to be related to ferm detecting that the subchain
>> ethic.eth1 is defined twice - however, I can't see that it is.
>>
>> Am i doing something wrong or is this a harmless parser bug?
>
>
> You have a chain nested inside a chain, which is wrong.
>
> I don't know what actually happens, I assume that the innermost chain will
> be
> used for the section where it is defined, but you should likely reorder your
> lines
> something like this (rough sketch, untested):
>
> table filter {
>     chain FORWARD {
>         policy DROP;
>         # connection tracking
>         mod state state INVALID DROP;
>         mod state state (ESTABLISHED RELATED) ACCEPT;
>
>     }
>
>     interface eth0 outerface eth1 @subchain eth0.eth1 {
>         chain dns {
>                   daddr 1.2.3.4 ACCEPT;
>                   daddr 5.6.7.8 ACCEPT;
>         }
>         chain FORWARD protocol (udp tcp) dport 53 realgoto dns;
>     }
> }
>
> Auke

I assume that you are saying that this is a ferm design decision?
Given that the only concept of nesting chains in iptables is in how
you call them, they are all top-level unscoped objects wherever they
might be 'defined'.

What I am actually trying to achieve is to be able to include
(reusable) chain definitions dynamically via the include mechanism -
but I can probably rejig to fit in line with the requirement.

Curiously, if you do define multiple nested chains, ferm produces a
warning but still outputs the right iptables commands to create and
call said chains.

Cheers,

Bret