> On Tue, Oct 20, 2015 at 02:37:46PM +0200, giorgio.nicole@xxxxxxxx wrote:
> > Hi,
> >
> > thanks for your answer,
> >
> > your answer to the first question confirms what I already supposed,
> > my workaround is now to add a last 'drop' rule to the input table
> > instead of changing the table policy:
> >
> > add rule inet filter input drop
> >
> > instead of
> >
> > add chain inet filter input { policy drop; }
>
> You also can specify the policy by the time you create the basechain
> in one go:
>
> add table inet filter
> add chain inet filter input { type filter hook input priority 0; policy
> drop; }
>
>
Hi,
that's right but my main script fw_basic.nft should be a read only file;
the dynamic behavior should result from the content of the included files
at the end of the script.
...
include "/var/lib/nftables/user.nft"
include "/var/lib/nftables/dnats.nft"
In my target system I have two configuration programs/daemons: the first
generates the nft file '/var/lib/nftables/user.nft' with rules from the user, the
second generates dnat rules (actually one rule with a set of multiple targets)
on the basis of zeroconfig-found devices in the file '/var/lib/nftables/dnats.nft';
The main nft script then includes both the generated files actually implementing
a dynamic firewall config.
This also works in case the user, for example, disables his part of the configuration:
in this case the file '/var/lib/nftables/user.nft' will be empty and the next call to the script
'/etc/nftable/fw_basic.nft' will actually (atomically) remove the user configs from the firewall.
giorgio
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
