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

[Wolfgang Bumiller]

On Mon, Feb 06, 2017 at 03:59:40PM +0100, Stefan Priebe - Profihost AG wrote:
> Hi,
> 
> sorry don't know how to teach thunderbird to not break lines. But i
> could sent the mail again using pastebin. Just request. Sorry again.

Not sure how I feel about that. Pastebins have a tendency to be erased
from history, making the mail archive less useful.
Anyway...

> 
> Am 06.02.2017 um 14:59 schrieb 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.
> 
> Mhm that's even more strange. The default group is this one:
> http://pastebin.com/raw/HAxJkhv7
> 
> So there's even a drop at the end of this group. So ACCEPT should not be
> reachable at all.
> 
> My test is a tcp connect to port 3306 which works just fine.
> 
> Here both again:
> Group:
> http://pastebin.com/raw/HAxJkhv7
> 
> monitoring list:
> http://pastebin.com/raw/4QeCYEVe

So what IP address are you connecting from? (If it's not one part of
this list, maybe there's a rogue nat rule masquerading it by accident?
(Since DROP rules appear as-is, you could try inserting a drop rule for
the exact IP you're coming from and destination port you're targetting
just before the group rule (and also try putting it afterwards) to see
if that's the case.)

> iptables tap in:
> http://pastebin.com/raw/1QVTJG8K