Ubiquiti all but confirms breach response iniquity

Re:Ubiquiti all but confirms breach response iniquity by dijit on Sunday April 04, 2021 @06:14PM (#26693295)

If you’re really asking, and not making a point;

PF is created and primarily maintained by OpenBSD

OpenBSD’s base system (without extra packages) includes PF and has a focus on security.

PF in freebsd is several major versions old.

nftables (like iptables before it) is rule based and not bucket based. So high numbers of rules will not affect pf’s performance like it does with nftables.

But, for home users, probably not noticeable. Though I prefer the syntax of PF personally.

[ Parent | on HN ]

Re:Ubiquiti all but confirms breach response iniquity by hyperpl on Sunday April 04, 2021 @06:21PM (#26693345)

Wireguard has also been stable on OpenBSD which helped me with my throughput on my apu2d router hardware.

[ Parent | on HN ]

Re:Ubiquiti all but confirms breach response iniquity by fuzzy2 on Sunday April 04, 2021 @06:27PM (#26693375)

Could you expand on what you mean by "bucket based"? Maybe the so-called "tables"? They sound pretty identical to ipset on Linux.

[ Parent | on HN ]

Re:Ubiquiti all but confirms breach response iniquity by dijit on Sunday April 04, 2021 @06:53PM (#26693543)

Here's how a packet flows through netfilter[0], and here's how it flows through pf[1].

[0]: https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilte...

[1]: http://mailing.openbsd.misc.narkive.com/jtIB9W3w/pf-packet-f...

[ Parent | on HN ]

Re:Ubiquiti all but confirms breach response iniquity by ta20210405 on Monday April 05, 2021 @03:30AM (#26696249)

>nftables (like iptables before it) is rule based and not bucket based.

What does this even mean? Do you have any documentation to explain?

>So high numbers of rules will not affect pf’s performance like it does with nftables.

This is wrong. From OpenBSD documentation:

"More lines being evaluated for each packet will result in slower performance."

[0]https://www.openbsd.org/faq/pf/perf.html

It's not 2001 any more. Nftables and Linux have left the BSDs in the dust.

[ Parent | on HN ]

Re:Ubiquiti all but confirms breach response iniquity by dijit on Monday April 05, 2021 @05:31AM (#26696952)

The key is “for each packet”, because it’s bucket based it will entirely skip evaluation for packets that do not match. This is due to how the rule set is compiled, but I can see how it could be confusing if you’re used to iptables and only think in those terms.

I posted the architectural diagrams of both in another comment on this thread yesterday, I think you missed that.

[ Parent | on HN ]

Re:Ubiquiti all but confirms breach response iniquity by ta20210405 on Monday April 05, 2021 @07:20AM (#26697603)

>The key is “for each packet”, because it’s bucket based it will entirely skip evaluation for packets that do not match.

That is how it works in nftables.

>but I can see how it could be confusing if you’re used to iptables and only think in those terms.

Considering you're misunderstanding some basics about nftables and iptables here, I think you need to look in the mirror.

>I posted the architectural diagrams of both in another comment on this thread yesterday, I think you missed that.

I saw, and it only reenforced the fact that that's how nftables works. Hilariously enough, the OpenBSD webpage crashed and wouldn't load, giving various 500 and 42X errors.

[ Parent | on HN ]

Re:Ubiquiti all but confirms breach response iniquity by ta20210405 on Tuesday April 06, 2021 @12:35PM (#26713975)

Here is an article that covers performance between Linux and FreeBSD, and it leaves BSD in the dust: https://matteocroce.medium.com/linux-and-freebsd-networking-...

Also, it specifically outlined how more rules slow down of on FreeBSD, and how poor multicore support is on pf.

[ Parent | on HN ]