mrlesmithjr / ansible-shorewall

ansible-shorewall

Installs and configures Shorewall firewall (http://shorewall.net)

Build Status

GitHub Actions

Travis CI

Requirements

For any required Ansible roles, review: requirements.yml

Role Variables

defaults/main.yml

Dependencies

Example Playbook

playbook.yml

License

MIT

Author Information

Larry Smith Jr.

• @mrlesmithjr
• [email protected]
• http://everythingshouldbevirtual.com

NOTE: Repo has been created/updated using https://github.com/mrlesmithjr/cookiecutter-ansible-role as a template.

ansible-shorewall's Issues

shorewall_params_host?

IMHO it would be useful to add shorewall_params_host which would add additional parameters which are local to particular host and don't need to be stored in main configuration.

If you think it's OK idea, please confirm, I will provide a PR.

Refactor CI testing, etc. based on Cookiecutter template

Need to refactor role and implement new CI flow based on https://github.com/mrlesmithjr/cookiecutter-ansible-role

restart shorewall immediatly at the end of role

Sometimes, when using this role in a playbook, you also use another role or tasks in the same playbook, later, that needs network and firewall rules to be configured.

Right now, shorewall restart after configuration is done via a handler that is executed at the end of the playbook, so firewall rules configured are not available before the very end of the playbook.

An option is needed to immediatly apply configured rules and not wait until the end of the playbook run.

Debian 10 Buster compatibility

Debian 10 alias Buster comes with shorewall 5.2 (version 5.2.3.2 at the time of writing on my system).
Shorewall check complains with the following message: ERROR: Unknown Action (Drop) in DROP_DEFAULT setting /usr/share/shorewall/actions.std (EOF)
The message is a little bit misleading, since the definition of DROP_DEFAULT is set in /etc/shorewall/shorewall.conf.

When I replace the following section unter DEFAULT ACTIONS/MACROS

ACCEPT_DEFAULT=none
DROP_DEFAULT=Drop
NFQUEUE_DEFAULT=none
QUEUE_DEFAULT=none
REJECT_DEFAULT=Reject

with this one

ACCEPT_DEFAULT="none"
BLACKLIST_DEFAULT="dropBcasts,dropNotSyn,dropInvalid"
DROP_DEFAULT="Broadcast(DROP),Multicast(DROP)"
NFQUEUE_DEFAULT="none"
QUEUE_DEFAULT="none"
REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP)"

shorewall check does not complain anymore.

Would it be possible to add an alternative template file for shorewall.conf for Debian Buster with these settings?
Another option would be to configure these options via variables.

IPv6 support (shorewall6)

Even though most traffic is still IPv4, it feels like the pressure to support IPv6 is getting stronger.
Providers are raising their prices for IPv4 and I just received an email from a german provider which explains the option to opt out for IPv4 addresses on servers to save money.
Long story short: I'm thinking of supporting IPv6 on more and more of my systems.

It would be great if we could extend this role with support for IPv6.

From what I extracted from https://shorewall.org/IPv6Support.html there is no integrated IPv6 support in the standard shorewall package. Instead, there is a package shorewall6 which handles everything IPv6 related independently from the standard shorewall configuration.
This makes sense, since it is totally possible to have hosts with IPv4 only, IPv6 only, or both.
Luckily, the config files for shorewall6 are pretty much the same as for shorewall. They just reside in another folder /etc/shorewall6 with the same file names and structure. There are a few exceptions listed under the link above.

It would be possible of course, to have shorewall configured with ansible and manually install and maintain shorewall6 beside of that. Another option would be to create an additional role for shorewall6.
But it would be very efficient to manage both with one role and with one var-namespace.
For example, we could add an option ipversion to the rules dictionary which defaults to ipv4 but could be set to ipv6 or both. The later value would enable to have one rule-entry for IPv4 and IPv6 which makes it much easier to manage rules consistently.

Are there any thoughts on this topic?

Extending rules template to support ORIGINAL DEST

I have the requirement to set the field ORIGINAL DEST in /etc/shorewall/rules in order to be able to match specific target IP's on a server.
This field is the seventh parameter in a rule definition, right after SOURCE PORT(S) which is also not filled by the current template.

As far as I see, there is just the line nr. 6 in templates/etc/shorewall/rules.j2 to be modified in order to achieve this:

{{ rule.action }}   {{ rule.source }}   {{ rule.dest }}   {{ rule.proto }}   {{ rule.dest_ports|join (',') }}   {{ rule.source_ports|join (',') }}   {{ rule.original_dest }}

Another idea (that has also been addressed in the pull request #18) is to add support for comments.

This could be done by adding these three lines right before the rule line inside the loop:

{% if rule.comment|length %}
#{{ rule.comment }}
{% endif %}

Of course this is not a issue, it is more a suggestion. I think it would be easy to apply and should not break something because if the variables are empty the template expands to the same rule line.
What do you think?

Btw. just want to say thank you for your ansible role. It is the most often used role in my playbooks.