[Ferm] Parser error or user error ...

[Auke Kok]

On 01/01/2016 01:07 AM, Bret Giddings wrote:
> 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.

I didn't think the @subchain was the problem, I actually thought it was 
the "chain dns" part.

The warning is a courtesy notice that you may have likely done something 
you didn't want (in most cases). In your cases, it's a false positive.

Auke