Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Aug 2015 16:36:48 +0200
From:      Damien Fleuriot <ml@my.gd>
To:        Kolontai Andrej <Andrej.Kolontai@verwaltung.uni-muenchen.de>
Cc:        "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org>
Subject:   Re: Machine freezes when loading pf ruleset
Message-ID:  <CAE63ME4bWEMk8RSQpoZ5vFn9pF5TnieVxbpV2%2B4vFYM9G7jy1g@mail.gmail.com>
In-Reply-To: <894145A3DDBDEF4880E00D334DCD87263EC814A8@MXS2.zuv.uni-muenchen.de>
References:  <b248a69a-0768-4e55-b2a2-4571e28b858f@CASHTS1.zuv.uni-muenchen.de> <CAE63ME69-J-bh9%2B0cPA6w%2BXAPAm1D08S7uvfi1O9bQyNE_ju1A@mail.gmail.com> <894145A3DDBDEF4880E00D334DCD87263EC814A8@MXS2.zuv.uni-muenchen.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On 26 August 2015 at 16:09, Kolontai Andrej <
Andrej.Kolontai@verwaltung.uni-muenchen.de> wrote:

> >1.5k rules seems like a lot for PF to handle.
> >
> >Is that 1.5k rules you've written in the conf, or 1.5k rules from `pfctl
> -sr | wc -l' ?
>
> Yes, that's what is in the conf files. The latter command gives around
> 3400...
>
> >I would suggest you find a way to drastically lower that.
>
> Given the number of networks, devices and applications that seems to be
> difficult. Also, we have some policies on our firewall which contribute to
> the large number of rules:
> * strict minimum principle. Only traffic that is explicitly needed passes
> the fw. That gives a lot of combinations.
> * most rules are either "pass in" or "pass out" . So every connection
> needs to have a pass in and a pass out rule. This does not mean that we
> have every rule twice. It's just that inbound and outbound policies are
> different things and we try not to mix them (accidently).
> * using "quick" is actually not allowed except in very special cases as it
> tends to cause unexpected side effects.
>
> What we do is, of course, using tables and anchors to make the evaluation
> of the rule set as efficient as possible.
>
> I need to say that in normal operation, the machines perform really well
> with absolutely no sign of shortage in any resource.
>
> A typical top screen looks like this:
>
> last pid: 59875;  load averages:  0.29,  0.33,  0.36
>
>                                      up 0+02:55:51  15:02:22
> 38 processes:  1 running, 37 sleeping
> CPU:  0.0% user,  0.0% nice,  0.0% system,  0.7% interrupt, 99.2% idle
> Mem: 3588K Active, 1883M Inact, 2333M Wired, 2037M Buf, 89G Free
> Swap: 117G Total, 117G Free
> ...
>
> There's plenty of memory and cpu power. Networking is (physically) capable
> of 40 gbit/s  (4 aggregated 10 gbit links). I have never seen a cpu load
> higher than 1.something.
>
> The problem occurs only in the moment I load the ruleset and only if the
> machine is in master state. If I only knew what is happening at that
> point... I can't make any sense of the log outputs.
>
> >You may also wish to ensure :
> >- you're using, if at all possible, a *dedicated* pfsync link (like a
> cable on a dedicated interface between the boxes)
>
> Yes, to some degree that is true. Pfsync runs over separate physical
> interfaces. But the machines are at different places. That means that the
> pfsync net is in fact just another vlan which runs over the same fiber link
> as everything else. Yes, we used to use IPsec to secure it. Right now,
> Ipsec is turned off for pfsync to exclude the possibility that this causes
> the problem. But that's apparently not the case. It still happens.
>
>
>

Well the machine seems to be very apt for the job indeed with plenty of
spare resources.

While I believe your filtering on egress traffic to be somewhat redundant
since you already filter inbound connections, it is not my place to comment
on that, not to mention that would certainly entail huge changes on your
side.


I do believe however that when you reload the ruleset PF sets some kind of
a lock.

I'm afraid I'm not familiar enough with the internals of PF to dig deeper
into this, but that may be worth a look into.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE63ME4bWEMk8RSQpoZ5vFn9pF5TnieVxbpV2%2B4vFYM9G7jy1g>