and aliases help to make that task easier.
While all configuration is stored on the cluster file system, the
-`iptables`-based firewall runs on each cluster node, and thus provides
+`iptables`-based firewall service runs on each cluster node, and thus provides
full isolation between virtual machines. The distributed nature of
this system also provides much higher bandwidth than a central
firewall solution.
or on a *Node* -> *Firewall*), or you can edit the configuration files
directly using your preferred editor.
-Firewall configuration files contains sections of key-value
+Firewall configuration files contain sections of key-value
pairs. Lines beginning with a `#` and blank lines are considered
-comments. Sections starts with a header line containing the section
+comments. Sections start with a header line containing the section
name enclosed in `[` and `]`.
reduce output to the log file.
Further, only some dropped or rejected packets are logged for the standard rules.
+// TODO: describe standard/default rules and note which of them get logged
+
In order to log packets filtered by user-defined firewall rules, it is possible
to set a log-level parameter for each rule individually.
This allows to log in a fine grained manner and independent of the log-level
-defined for the standard rules.
-In particular, each rule is logged independently from the log-level set for the
-standard rules in the firewall `Options`.
+defined for the standard rules in the firewall `Options`.
The log level for the rule can also be set via the firewall configuration file by
appending a `-log <loglevel>` to the selected rule.
-Here, `<loglevel>` is one of the following flags, attached to the log output:
+Here, `<loglevel>` is one of the following flags:
`nolog, emerg, alert, crit, err, warning, notice, info, debug`
-For example:
+For example, the following two are ident:
----
IN REJECT -p icmp -log nolog
-----
-
-is the same as
-
-----
IN REJECT -p icmp
----