Hello,
> >
> > So how people feel about changing '-Fa' to kill all rules and tables, not
> > just
> > those, which are attached to main ruleset (root)?
> >
> > thanks and
> > regards
> > sashan
> >
>
> IMHO this is a needed feature, but I agree with your hesitation about
> using -Fa. This
On 2019/03/26 09:38, Alexandr Nedvedicky wrote:
> On Mon, Mar 25, 2019 at 10:28:40PM -0400, Ted Unangst wrote:
> > Alexandr Nedvedicky wrote:
> > > it is, however -Fall operates on main ruleset only. -Fall also does
> > > not reset limits and timeouts. Hence my first idea was to introduce
On Mon, Mar 25, 2019 at 10:28:40PM -0400, Ted Unangst wrote:
> Alexandr Nedvedicky wrote:
> > it is, however -Fall operates on main ruleset only. -Fall also does
> > not reset limits and timeouts. Hence my first idea was to introduce
> > '-FNuke', which kills all rulesets and tables.
>
Alexandr Nedvedicky wrote:
> it is, however -Fall operates on main ruleset only. -Fall also does
> not reset limits and timeouts. Hence my first idea was to introduce
> '-FNuke', which kills all rulesets and tables.
>
> I don't want to change behaviour of existing option
Alexandr Nedvedicky wrote:
> how about making the '-U' (or whatever name we agree) undocumented. We can
> also make the option available if pfctl will get compiled with 'DEBUG'
> option (assuming we are doing regress on debug bits anyway).
no, it should be documented.
but few
Hello,
> > > > Isn't -U pretty close to -Fall ?
> > > >
> > >
> > > it is, however -Fall operates on main ruleset only. -Fall also does
> > > not reset limits and timeouts. Hence my first idea was to introduce
> > > '-FNuke', which kills all rulesets and tables.
> > >
> > > I
Theo de Raadt(dera...@openbsd.org) on 2019.03.24 10:22:25 -0600:
> Alexandr Nedvedicky wrote:
>
> > On Sun, Mar 24, 2019 at 09:51:13AM +0100, Denis Fondras wrote:
> > > On Sun, Mar 24, 2019 at 09:24:34AM +0100, Alexandr Nedvedicky wrote:
> > > > I think all the above calls for a new standalone
Alexandr Nedvedicky wrote:
> On Sun, Mar 24, 2019 at 09:51:13AM +0100, Denis Fondras wrote:
> > On Sun, Mar 24, 2019 at 09:24:34AM +0100, Alexandr Nedvedicky wrote:
> > > I think all the above calls for a new standalone option, which I named as
> > > 'Unconfigure'. Patch below suggest
On Sun, Mar 24, 2019 at 09:51:13AM +0100, Denis Fondras wrote:
> On Sun, Mar 24, 2019 at 09:24:34AM +0100, Alexandr Nedvedicky wrote:
> > I think all the above calls for a new standalone option, which I named as
> > 'Unconfigure'. Patch below suggest unconfigure behavior for PF.
> > Doing 'pfctl
On Sun, Mar 24, 2019 at 09:24:34AM +0100, Alexandr Nedvedicky wrote:
> I think all the above calls for a new standalone option, which I named as
> 'Unconfigure'. Patch below suggest unconfigure behavior for PF.
> Doing 'pfctl -U' will bring PF back to its initial state (e.g. right before
>
Hello,
I received a feedback suggesting to come up with better name than 'Nuke'
> not sure about the name.
>
> i've often want a similar operation for network interfaces, which
> returns them to 'raw' state.
>
> and there's also been people who want the same for the routing
> table
>
> if we
Hello,
I'm giving up on identifying unreferenced/orphaned rulesets. It seems to me
like too much work/complexity, which invites more troubles. I prefer to keep
things simple, hence I'm proposing new modifier for Flush option:
-F Nuke Flush all rulesets and tables.
The option is meant
On Fri, Feb 22, 2019 at 03:02:07PM +0100, Alexandr Nedvedicky wrote:
> so the option '-F Anchors' will also perform a '-Fr' on main ruleset, is
> that correct?
No, my `-f /etc/pf.conf' is the equivalent to your `-F rules' here.
> And also one more thing, which comes to my mind. How
Hello Klemens,
I just need to clarify some details.
> > the 'unreferenced' means the anchor is not reachable by any packet.
> > like there is no path for packet between main ruleset and that
> > particular
> > anchor (and all its descendants).
> Yes. With the regress suite for
On Fri, Feb 22, 2019 at 12:42:02PM +0100, Alexandr Nedvedicky wrote:
> yes, that's what I thought. We have a kind 'service' on Solaris, which
> wraps pfctl to manage firewall. If firewall is being enabled, the service
> cleans up all rules (anchors). We basically dump the rulesets
Hello,
On Fri, Feb 22, 2019 at 10:55:17AM +0100, Klemens Nanni wrote:
> On Fri, Feb 22, 2019 at 01:52:24AM +0100, Alexandr Nedvedicky wrote:
>
> > so far so good. Now let's flush the rules from kernel:
> >
> > lumpy# ./pfctl -Fr
> > rules cleared
> > lumpy# ./pfctl -sr
> >
On Fri, Feb 22, 2019 at 01:52:24AM +0100, Alexandr Nedvedicky wrote:
> so far so good. Now let's flush the rules from kernel:
>
> lumpy# ./pfctl -Fr
> rules cleared
> lumpy# ./pfctl -sr
> lumpy#
>
> However the underscore anchors are still there:
Any unreferenced anchor will
Hello,
This issue has been reported by one of our customers.
consider pf.conf comes with rules as follows:
anchor {
pass all
anchor {
block all
}
}
We load pf.conf to kernel and (pfctl -f pf.conf) and display what got loaded:
18 matches
Mail list logo
