<div dir="ltr">In my previous job we had to build a firewall solution for our OpenStack control plane. Our research found that firewalld may have a habit of 'fighting' against the rules added by certain OpenStack services. This was over a year ago, so things may have changed. We didn't pursue firewalld as a solution, so perhaps these issues are non-existent or surmountable.<div><br></div><div>The solution we built used a conf.d/ mechanism layered on top of iptables. An advantage of this approach is that operators or co-resident software stacks could add their own rules to the firewall. AFAIK, this is not generally possible when using iptables-save/restore as it relies on a single configuration file which must be 'owned' by something - in this case presumably OSA.</div><div><br></div><div>I'm not suggesting that you reimplement the solution I've described, but it does outline one benefit of firewalld - OSA would not need to entirely own the firewall configuration.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 July 2017 at 07:49, Markos Chandras <span dir="ltr"><<a href="mailto:mchandras@suse.de" target="_blank">mchandras@suse.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 07/26/2017 05:59 PM, Major Hayden wrote:<br>
><br>
> firewalld disadvantages<br>
<span class="">> -----------------------<br>
> 1) Different distributions have different base rule sets<br>
<br>
</span>Also different distributions offer different version of firewalld which<br>
means different behavior and possibly bugs between them. The Ansible<br>
module may not always 'mask' such things we either going to spend time<br>
improving the module or workaround all these in our playbooks. Improving<br>
the upstream module of course is a good thing but I just wanted to point<br>
out the maintenance cost of that.<br>
<span class=""><br>
> 2) Medium/High complexity rules require --direct, which is like using iptables anyway<br>
> 3) It's another daemon to manage/monitor<br>
> 4) We wouldn't be able to use firewalld's "zones" very heavily<br>
> 5) Saving/restoring iptables rules is battle-tested already<br>
<br>
</span>I am slightly in favor of iptables (or even nftables) mostly because<br>
they provide a stable known interface which can work for simple and<br>
complex rules. As your 2nd point above correctly states, if we start<br>
using the 'direct' rule feature of firewalld, then we will end up having<br>
a mixture of pure firewalld and iptables rules which may not be the<br>
cleaner option in terms of maintainability.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
markos<br>
<br>
SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton<br>
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>