[pve-devel] pve-firewall / current git master

[Wolfgang Bumiller]

First a general note (for everyone on the list actually):
Please don't let your mail clients line-break command outputs, it steals
way too much of my time reading this :-\.
(And please prefer iptables-save style output over iptables -L...,
iptables -L is just horrible. I'm so looking forward to when we can
finally use `nft list ruleset` instead...)

Reply inline:

On Mon, Feb 06, 2017 at 11:25:44AM +0100, Stefan Priebe - Profihost AG wrote:
> Hi,
> 
> after upgrading my test cluster to latest git versions from 4.3. I've no
> working firewall rules anymore. All chains contain an ACCEPT rule. But
> i'm not sure whether this was also the case with 4.3. But it breaks the
> rules.
> 
> The chains is this one:
> # iptables -L tap137i0-IN -vnx
> Chain tap137i0-IN (1 references)
>     pkts      bytes target     prot opt in     out     source
>    destination
>        0        0 DROP       udp  --  *      *       0.0.0.0/0 0.0.0.0/0            udp dpt:67
>        0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0 0.0.0.0/0            match-set PVEFW-0-officeips-v4 src tcp dpt:443
>        1       52 ACCEPT     tcp  --  *      *       0.0.0.0/0 0.0.0.0/0            match-set PVEFW-0-ph-networks-v4 src tcp dpt:22
>       66     3040 GROUP-ph_default_group-IN  all  --  *      * 0.0.0.0/0            0.0.0.0/0
>       33     1716 ACCEPT     all  --  *      *       0.0.0.0/0 0.0.0.0/0            mark match 0x80000000/0x80000000
>        0        0 PVEFW-Drop  all  --  *      *       0.0.0.0/0 0.0.0.0/0
>        0        0 DROP       all  --  *      *       0.0.0.0/0 0.0.0.0/0
>        0        0            all  --  *      *       0.0.0.0/0 0.0.0.0/0            /* PVESIG:zR5Xk5kxEPWmHBeoIDiNXxCERrg */
> 
> But all packets get accepted by:
>       33     1716 ACCEPT     all  --  *      *       0.0.0.0/0 0.0.0.0/0            mark match 0x80000000/0x80000000
> 
> what is this?

Our "sub"-chains (like groups) generally avoid using ACCEPT directly and
instead set a mark and RETURN. (In many cases this is not strictly
necessary but it is more flexible and could potentially allow more
complex rules (like nesting groups or something, if we ever want that)).
So the input rules of ph_default_group would be responsible for setting
this bit in your case above.