nexedi / slapos.package

For reference, here are the shorewall/shorewall6 configs I do for re6st (only showing the re6st-specific parts).

shorewall/rules:

ACCEPT          net             $FW             tcp     openvpn

shorewall6/shorewall6.conf:

IP_FORWARDING=Keep

(maintainer version in my case contains IP_FORWARDING=Off, while shorewall/shorewall.conf does contain IP_FORWARDING=Keep)

shorewall6/zones:

re6st   ipv6

shorewall6/interfaces:

re6st   re6stnet+       tcpflags,routeback

shorewall6/policy:

$FW             re6st           ACCEPT
re6st           $FW             DROP            info
re6st           all             DROP            info

shorewall6/rules:

Ping(ACCEPT)    re6st           $FW

# re6st rules
# man re6stnet:
#   re6st nodes use UDP port 326 to communicate.  It must be open on all re6st IPv6.
ACCEPT          re6st           $FW             udp     326
#   UDP port 6696 must be open on link-local IPv6 of all interfaces managed by Babel.
#   XXX: how to apply rule only to link-local ?
ACCEPT          re6st           $FW             udp     6696

And of course, shorewall6/rules must also contain rules controling access to whatever services should be accessible. A typical example could be:

ACCEPT          re6st           $FW             tcp     http
ACCEPT          re6st           $FW             tcp     https

Important note: re6st making it possible for any node to become a man-in-the-middle (because of the peer-to-peer routing approach - ie, it's not a re6st bug and cannot be solved at re6st level), source-ip-based rules are always meaningless on re6st network. I have checked IPSEC a bit a year ago, which looks like it could solve the issue at just the right level to make firewall rules relevant again (they get applied after kernel validated the signature on IP headers), but I could not find a key exchange mecanism which would scale without direct participation of both ends' sysadmins (which would extremely impractical for apache frontends, for example).

Can you instead remove, create a new roles which sets this firewall configuration, if the role is loaded on the playbook (what we want on vifib.yml) it get it working?

This was added for a person which don't know about networking or firewall setups at their machine. The idea is get re6st-node working at any cost without require understand it.

Playbook is a blackbox designed for 99.9% of the users and not for the 0.1% which has some special configuration. The person which understand, can disable the crontab easily if he wants.

Also consider the case, people install re6st on a machine which comes with firewall by default (Ubuntu Desktop and maybe Ubuntu Server too).

You seems to miss the most important point: a misconfigured firewall is bad for the whole re6st network.

Can you instead remove, create a new roles which sets this firewall configuration, if the role is loaded on the playbook (what we want on vifib.yml) it get it working?

I'm not sure to understand. In any case, I don't want such cron task for vifib.yml (and more generally inside our networks).

The person which understand, can disable the crontab easily if he wants.

And more generally, when ansible is called regularly, one should not revert manually what ansible does.

Playbook is a blackbox designed for 99.9% of the users and not for the 0.1% which has some special configuration.

Sure, I'm not trying to make playbooks perfect so that it can handle all special configuration. But as written previously, that can't apply to re6st, which is too sensitive.

You seems to miss the most important point: a misconfigured firewall is bad for the whole re6st network.

The missconfiguration can be done with or without this script, even a detailed documentation can lead to a user which wish to use a firewall create same "blackhole" configuration like this. Don't you think? If we explain which port to open, people can just type ip6tables commands.

So I'm sure re6stnet can prevent himself to become a blackhole, as once in a while, someone can missconfigure something.

So, if this can create a missconfiguration, we must replace by something which cannot create blackwholes, IMHO, what we cannot do is let peple get failures before setup re6stnet (this will kill any adoption or gnet services). This MUST be designed to massive adoption. It was important to remark that, this script was introduced after a user fail to start re6stnet on a server with firewall.

I'm happy if you can contribute to a better solution (design, code, whatever), else we must keep this until something better replace it, else, it will increase too much support/complaints. In any case, I plan to work on re6stnet a bit soon (plan is next week or earlier).

Notice, this ansible playbook is not exactly part of re6stnet, it is a wrapper out of re6stnet to attempt to configure the machine in most effective way (you can consider as a hack), with the most chances that re6st work. If I would wrote a tutorial, It would explain to do the same as those scripts.... so it is probably better verbose information on the script/ansible to inform that ports are been open and probably a better configuration should be placed.

/cc @jp as he also want that we automate 100% of the slapos/re6stnet setup (the best doc is no need a doc).

it will increase too much support/complaints

I prefer complaints that it does not work at all (and fix for good), than no immediate complaint and poor network.

This MUST be designed to massive adoption

and massive bad reputation due to unreliability ?

the best doc is no need a doc

Yes, but again, firewalls are firewalls. There's really no way to automate things in a generic way for people who choose to have a firewall, simply because everything is centralized and you can't plug into that safely.

Maybe nftables will improve this.

Take a look at fail2ban actions: they support many different firewalls explicitly, and the user has to choose the one that is appropriate. They would have never been adopted so massively if it was not done reliably.

What about selinux-enabled boxes and network managers like NetworkManager (this one in particular has the bad idea to manage the interfaces created by re6stnet, as well as messing up with routes) ?

I prefer complaints that it does not work at all (and fix for good), than no immediate complaint and poor network.

For a initial user, "not work at all" means he won't try ever again or ask questions. This is what we want to avoid, and we having been doing. The script is far far from perfect (done in 5 min to replace solve an ongoing problem), but no replacement for an hypotetical case where the user can make something bad by playing with firewall is not a good excuse for drop it. So let's discuss what is the best way to replace it.

and massive bad reputation due to unreliability ?

Do you have a concreate case where this happens due firewall settings? And how to detect unreliability on re6st? I'm interested to know.

Yes, but again, firewalls are firewalls. There's really no way to automate things in a generic way for people who choose to have a firewall, simply because everything is centralized and you can't plug into that safely.

What are the odds to fail and what are the risk? If we cannot be perfect, we can be correct for the 99% of the cases.

Take a look at fail2ban actions: they support many different firewalls explicitly, and the user has to choose the one that is appropriate. They would have never been adopted so massively if it was not done reliably.

Great, so we can evolve on this direction, thanks for the link. This is probably what will be requires to implement in the end to replace ad-hoc script that I added.

What about selinux-enabled boxes and network managers like NetworkManager (this one in particular has the bad idea to manage the interfaces created by re6stnet, as well as messing up with routes) ?

We must add tasks to ansible to solve all those problems (notice, we can ask "Do you want to disable selinux else re6stnet would not work ") and so on...) or make re6stnet circuvent those problems, no other way....