On Mon, 15 Apr 2024, at 21:33, Thomas wrote:
> Hi all,
>
> I'm greatly enjoying OpenBSD and have it on most of my devices as I try
> to set up my "perfect lab". I would like some feedback / thoughts about
> one behaviour which I don't quite get.
>
> I have a VM for the world facing side of my
Hi all,
I'm greatly enjoying OpenBSD and have it on most of my devices as I try to set
up my "perfect lab". I would like some feedback / thoughts about one behaviour
which I don't quite get.
I have a VM for the world facing side of my network. I have a wireguard network
to link it up to a
> I don't think there is at present. There are no "only use v4" or "only
> use v6" addresses modifiers, and pf isn't figuring out for itself that
> it only makes sense to use addresses from the relevant family for
> af-to translation addresses (although it _does_ do
" or "only
use v6" addresses modifiers, and pf isn't figuring out for itself that
it only makes sense to use addresses from the relevant family for af-to
translation addresses (although it _does_ do this for nat-to).
>> Regarding the other rules and tests, the ::1 rule is wro
> Try changing ($wan:0) to $(wan) and see what happens.
Huh, that worked! Thanks!
Try changing ($wan:0) to $(wan) and see what happens.
> Can you try if the same happens with a more specific rule (for
> testing)?
>
> i.e.:
>
> pass in on igc3 inet6 from "put actual v6 prefix here" to 64:ff9b::/96
> af-to inet from "actual IP on igc0"/32
This worked! Specifically, I think the ($wan:0) was the problem. I
could've sworn I tried this
On 2024-03-15, Tobias Fiebig via misc wrote:
>
> Moin,
>> # perform nat64 (NOT WORKING)
>> pass in to 64:ff9b::/96 af-to inet from ($wan:0)
>
> Can you try if the same happens with a more specific rule (for
> testing)?
>
> i.e.:
>
> pass in on igc3 inet6 from "put actual v6 prefix here"
Moin,
> # perform nat64 (NOT WORKING)
> pass in to 64:ff9b::/96 af-to inet from ($wan:0)
Can you try if the same happens with a more specific rule (for
testing)?
i.e.:
pass in on igc3 inet6 from "put actual v6 prefix here" to 64:ff9b::/96
af-to inet from "actual IP on igc0"/32
I am
.google.com +short
ipv4.l.google.com.
64:ff9b::8efa:bc0e
However, the pf rule using af-to does not appear to do anything and
I haven't been able to figure out why. When I try to ping6, I get 100%
packet loss.
I inspected packets through tcpdump (after adding "log" to everything
htly
> > varying results. guess i should go back and test ix with LRO off on
> > the pf box.
>
> Sorry, I don't get your problem. You changed your firewall NICs from
> ix(4) to mcx(4) and the throughput got slower? Or, the speed it varying
> between 0.9 gbps and 1.0 gbps?
and ix)
em(4) does not support the LRO feature, just TSO with mglocker's diff.
> and very consistently getting close to the full 1gbps
> thruoghput on single tcp connections now instead of slower and slightly
> varying results. guess i should go back and test ix with LRO off on
> the pf
connections now instead of slower and slightly
varying results. guess i should go back and test ix with LRO off on
the pf box.
I have setup a transparent Tor proxy with the following pf ruleset:
https://paste.c-net.org/WharfSeasick
It routes most importantly all TCP and DNS traffic through the Tor network.
Now I want to have another rule for I2P bittorrent, meaning that there is a rule
for traffic that must be routed
> On Thu, Nov 30, 2023 at 03:55:49PM +0300, 4 wrote:
>>
>> "cbq can entirely be expressed in it" ok. so how do i set priorities for
>> queues in hfsc for my local(not for a router above that knows nothing about
>> my existence. tos is an absolutely unvia
On 2023/12/01 15:57, 4 wrote:
> >But CBQ doesn't help anyway, you still have this same problem.
> the problem when both from below and from above can be told to you "go and
> fuck yourself" can't be solved, but cbq gives us two mechanisms we need-
> priorities and traffic restriction. nothing
> On 2023-12-01, 4 wrote:
>I don't know why you are going on about SMT here.
i'm talking about not sacrificing functionality for the sake of hypothetical
performance. the slides say that using queues degrades performance by 10%. and
you're saying there won't be anything in the queues until an
6-fly, while ACKs would get priority of 7 and assigned to queue 7-ack.
Anyway, after years of usage, and lot of frustration in the beginning, I
find current approach more flexible, because in HFSC queue and priority
have to be the same, while in current pf we can set it to be exactly
like HFSC, but
>>> not a share of the total piece of the pie, and we don't need to know
>>> anything about the pie.
>
>> But unless you are sending more traffic than the *interface* speed,
>> you will be sending it out on receipt, there won't be any delays in
>> sending pac
and we don't need to know
>> anything about the pie.
> But unless you are sending more traffic than the *interface* speed,
> you will be sending it out on receipt, there won't be any delays in
> sending packets to the next-hop modem/router.
> There won't *be* any packets
hing
> about the pie.
But unless you are sending more traffic than the *interface* speed,
you will be sending it out on receipt, there won't be any delays in
sending packets to the next-hop modem/router.
There won't *be* any packets in the queue on the PF machine to send in
priority order.
> On Wed, 29 Nov 2023 00:12:02 +0300
> 4 wrote:
>> i haven't used queues for a long time, but now there is a need.
>> previously, queues had not only a hierarchy, but also a priority. now
>> there is no priority, only the hierarchy exists.
> It took me quite some time to wrap my head around
missing?
>>>
>>> man pf.conf
>>>
>>> Look for set tos. Just a few lines below set prio in the man age,
>>>
>>> You can have more then 8 if you need/have to.
>> > Only useful if devices upstream of the PF router know their available
>> band
ch queue.
Now all of the above is fine for home gateway with just "internet" and
"lan". Things get much more complicated if there are multiple VLANs on
internal interface, GRE / GIF of wireguard tunnels on external
interfaces etc.
I once had the privilege to sit with Henning, autho
On Thu, 2023-11-30 at 15:55 +0300, 4 wrote:
> "cbq can entirely be expressed in it" ok. so how do i set priorities
> for queues in hfsc
You stack HFSC with link-share service curves with linkshare criterion
1:0 - or in pf.conf(5) terms: "bandwidth 1" and "bandwidth 0".
Or you do not configure
need/have to.
Only useful if devices upstream of the PF router know their available
bandwidth and can do some QoS themselves.
Same can be said for CoS as well. You can only control what's going out
of your own network. After that as soon as it reach your ISP or what
not, you have no clue if t
ere running most certainly needed
> an upgrade anyway.
"cbq can entirely be expressed in it" ok. so how do i set priorities for queues
in hfsc for my local(not for a router above that knows nothing about my
existence. tos is an absolutely unviable concept in the real world) pf-router?
i don't see a word about it in man pf.conf
On Thu, Nov 30, 2023 at 03:55:49PM +0300, 4 wrote:
>
> "cbq can entirely be expressed in it" ok. so how do i set priorities for
> queues in hfsc for my local(not for a router above that knows nothing about
> my existence. tos is an absolutely unviable concept in the real
each connection, so even the basic bandwidth
> control can't really work, let alone prioritising access to the
> available capacity.
> Priorities work when you are trying to transmit more out of an interface
> than the bandwidth available on that interface.
> Say you have a box r
On Thu, Nov 30, 2023 at 02:57:23PM +0300, 4 wrote:
> so what happened to cbq? why such the powerful and useful thing was removed?
> or Theo delete it precisely because it was too good for obsd? %D
Actually, the new queueing system was done by Henning, planned as far back
as (at least) 2012
so what happened to cbq? why such the powerful and useful thing was removed? or
Theo delete it precisely because it was too good for obsd? %D
> You can have more then 8 if you need/have to.
Only useful if devices upstream of the PF router know their available
bandwidth and can do some QoS themselves.
h
control can't really work, let alone prioritising access to the
available capacity.
Priorities work when you are trying to transmit more out of an interface
than the bandwidth available on that interface.
Say you have a box running PF with a 1Gb interface to a
(router/modem/whatever) with an upli
yes, all this can be make without hierarchy, only with priorities(because hierarchy it's
priorities), but who and why decided that eight would be enough? the one who created cbq- he
created it for practical tasks. but this "hateful eight" and this "flat-earth"-
i don't understand what use they
th queues?
> the older ALTQ system was replaced by a whole new system back in OpenBSD 5.5
> (or actually, altq lived on as oldqeueue through 5.6), and the syntax is both
> very different and in most things much simpler to deal with.
> The most extensive treatment available is
tem back in OpenBSD 5.5
(or actually, altq lived on as oldqeueue through 5.6), and the syntax is both
very different and in most things much simpler to deal with.
The most extensive treatment available is in The Book of PF, 3rd edition
(actually the introduction of the new queues was the reason fo
i haven't used queues for a long time, but now there is a need. previously,
queues had not only a hierarchy, but also a priority. now there is no priority,
only the hierarchy exists. i was surprised, but i thought that this is quite in
the way of Theo, and it is possible to simplify the queue
ble to connect via either connection at any time without changing the
> default gateway.
>
> A long time ago under the old pf syntax I had this in /etc/pf.conf which
> worked fine, and as far as I can remember was the only thing needed to enable
> this desired behavior:
>
>
the default gateway.
A long time ago under the old pf syntax I had this in /etc/pf.conf which worked
fine, and as far as I can remember was the only thing needed to enable this
desired behavior:
pass in on $wan1_if reply-to ( $wan1_if $wan1_gw )
pass in on $wan2_if reply-to ( $wan2_if $wan2_gw
Thnx, this seems toasting better..
On Sat, Nov 11, 2023 at 06:32:26PM +0100, Daniele B. wrote:
>
> "Peter N. M. Hansteen" wrote:
>
> > something like the good old
> > https://home.nuug.no/~peter/pf/newest/log2syslog.html should still
> > work, I think.
> >
> > - Peter
>
&g
"Peter N. M. Hansteen" wrote:
> something like the good old
> https://home.nuug.no/~peter/pf/newest/log2syslog.html should still
> work, I think.
>
> - Peter
To disable pflogd completely what to you consider best:
ifconfig pflog0 down
or
pflogd_flags="-f /dev/null"
= Daniele Bonini
On 11.11.2023. 12:13, Stuart Henderson wrote:
> On 2023-11-11, Peter N. M. Hansteen wrote:
>> On Fri, Nov 10, 2023 at 08:23:54PM +0100, Hrvoje Popovski wrote:
>>> what would be best way to log pf logs in ascii and sent it to remote
>>> syslog ? I'm aware of pfl
On 2023-11-11, Peter N. M. Hansteen wrote:
> On Fri, Nov 10, 2023 at 08:23:54PM +0100, Hrvoje Popovski wrote:
>> what would be best way to log pf logs in ascii and sent it to remote
>> syslog ? I'm aware of pflow but I need ascii pf logs on remote syslog
>> server.
>
>
On Fri, Nov 10, 2023 at 08:23:54PM +0100, Hrvoje Popovski wrote:
> what would be best way to log pf logs in ascii and sent it to remote
> syslog ? I'm aware of pflow but I need ascii pf logs on remote syslog
> server.
something like the good old
https://home.nuug.no/~peter/
Hi all,
what would be best way to log pf logs in ascii and sent it to remote
syslog ? I'm aware of pflow but I need ascii pf logs on remote syslog
server.
I remember that it was on https://www.openbsd.org/faq/pf/logging.html
and that that section was removed.
Old version is on https
ion is,
"Would it be safe for me to start writing a PF book?"
My answer is no. There is no guarantee that the effort you put in will
give satisfactory-to-you returns in any form or fashion. Writing is a
time sink and publishers may or may not be interested.
On the other hand if y
Peter,
Any plans to update it?
R/,
Jay
> For those interested in physical copies of The Book of PF
> (https://nostarch.com/pf3)
> -- it has been out of print, only available in electronic formats for a while
> --
> I just got word from No Starch Press
Hello Valdrin,
I am also aware that attaching PF to more than one CPU will not be enough,
and I think I have been misunderstood; I do not reproach about this. Just a
curiosity on my part.
As far as I learned from users who wrote me private messages, OpenBSD does
not have a public RoadMap
can say that OpenBSD is more
successful with 1518 byte TCP packets rather than 64 byte UDP packets.
From: owner-m...@openbsd.org on behalf of Gábor LENCSE
Sent: Wednesday, October 25, 2023 18:47
To: misc@openbsd.org
Subject: Re: Parallel PF
Hello Valdrin,
10
see "SMP Improvements" in page: https://www.openbsd.org/72.html
Of course, I'm sure a lot will change when PF becomes mp-safe, but I believe
there is still time for that.
PF's performance can reach up to 10Gbps with the right CPU selection.
Expressing traffic in Gbps can be rather
. In fact, as far as I follow, there are some issues in the UDP_input
section.
Of course, I'm sure a lot will change when PF becomes mp-safe, but I believe
there is still time for that.
PF's performance can reach up to 10Gbps with the right CPU selection. Do you
have traffic that exceeds this? Maybe
softnet kernel tasks to 4 is definitely being considered on the
>> PF side too, but I would like to express my concern about timing. Do you
>> have any schedule for this?
>>
>> I think one of the common prayers of all OpenBSD users is that PF will
>> speed up. Thank you for reading and my best regards.
>>
>> --
>> Sam
>>
>
I'm sure that something like parallel IP forwarding and increasing the
> number of softnet kernel tasks to 4 is definitely being considered on the
> PF side too, but I would like to express my concern about timing. Do you
> have any schedule for this?
>
> I think one of the common pray
Hello dear OpenBSD team,
I'm sure that something like parallel IP forwarding and increasing the
number of softnet kernel tasks to 4 is definitely being considered on the
PF side too, but I would like to express my concern about timing. Do you
have any schedule for this?
I think one
Congratulations on a successful 7.4 release!
I'm writing with a gentle feature request for pf; I asked about this
functionality a long time ago and have seen a few other related questions on
the list since then. Now that I've played with another NAT64 implementation
(Jool), I think I can
> On 15 Sep 2023, at 18:54, Stuart Henderson wrote:
>
> On 2023/09/15 13:40, Andy Lemin wrote:
>> Hi Stuart,
>>
>> Seeing as it seems like everyone is too busy, and my workaround
>> (not queue some flows on interfaces with queue defined) seems of no
>> interest,
>
> well, it might be, but
On 2023/09/15 13:40, Andy Lemin wrote:
> Hi Stuart,
>
> Seeing as it seems like everyone is too busy, and my workaround
> (not queue some flows on interfaces with queue defined) seems of no
> interest,
well, it might be, but I'm not sure if it will fit with how
queues work..
> and my current
Hi Stuart,Seeing as it seems like everyone is too busy, and my workaround (not queue some flows on interfaces with queue defined) seems of no interest, and my current hack to use queuing on Vlan interfaces is a very incomplete and restrictive workaround;Would you please be so kind as to provide me
On Thu, Sep 14, 2023 at 7:23 PM Andrew Lemin wrote:
>
>
> On Wed, Sep 13, 2023 at 8:35 PM Stuart Henderson <
> stu.li...@spacehopper.org> wrote:
>
>> On 2023-09-13, Andrew Lemin wrote:
>> > I have noticed another issue while trying to implement a 'prio'-only
>> > workaround (using only prio
On Wed, Sep 13, 2023 at 8:35 PM Stuart Henderson
wrote:
> On 2023-09-13, Andrew Lemin wrote:
> > I have noticed another issue while trying to implement a 'prio'-only
> > workaround (using only prio ordering for inter-VLAN traffic, and HSFC
> > queuing for internet traffic);
> > It is not
rculating on tech@ for further
> > discussion? Queueing at bps resolution is rather redundant nowadays, even
> > on the very slowest links.
>
> tech@ is more for diffs or technical questions rather than not-fleshed-out
> quick ideas. Doing this would solve some problems with the &q
On 2023-09-13, Andrew Lemin wrote:
> I have noticed another issue while trying to implement a 'prio'-only
> workaround (using only prio ordering for inter-VLAN traffic, and HSFC
> queuing for internet traffic);
> It is not possible to have internal inter-vlan traffic be solely priority
> ordered
nowadays, even
> on the very slowest links.
tech@ is more for diffs or technical questions rather than not-fleshed-out
quick ideas. Doing this would solve some problems with the "just change it
to 64-bit" mooted on the freebsd-pf list (not least with 32-bit archs),
but would still
gt;> >
>> > I have discovered that PF's queueing is still limited to 32bit bandwidth
>> > values.
>> >
>> > I don't know if this is a regression or not.
>>
>> It's not a regression, it has been capped at 32 bits afaik forever
>> (certain
gt; > I don't know if this is a regression or not.
>
> It's not a regression, it has been capped at 32 bits afaik forever
> (certainly was like that when the separate classification via altq.conf
> was merged into PF config, in OpenBSD 3.3).
>
Ah ok, it was talked abou
r
(certainly was like that when the separate classification via altq.conf
was merged into PF config, in OpenBSD 3.3).
> I am sure one of the
> objectives of the ALTQ rewrite into the new queuing system we have in
> OpenBSD today, was to allo
larger than 4294M. Maybe I am
imagining it..
Anyway, I am trying to use OpenBSD PF to perform/filter Inter-VLAN routing
with 10Gbps trunks, and I cannot set the queue bandwidth higher than a
32bit value?
Setting the bandwidth value to 4295M results in a value overflow where
'systat queues' shows
gt; > > only four but five CPU cores were used by IP packet forwarding:
> > the packet processing is done in kernel threads (task queues are built
> > on threads), and those threads could be scheduled on any cpu. the
> > pf purge processing runs in yet another thread.
> >
threads (task queues are built
on threads), and those threads could be scheduled on any cpu. the
pf purge processing runs in yet another thread.
iirc, the schedule scans down the list of cpus looking for an idle
one when it needs to run stuff, except to avoid cpu0 if possible.
this is why you see most
et processing is done in kernel threads (task queues are built
on threads), and those threads could be scheduled on any cpu. the
pf purge processing runs in yet another thread.
iirc, the schedule scans down the list of cpus looking for an idle
one when it needs to run stuff, except to avoid c
from 4 to 5?*
What it more crucial for me, are the stateful NAT64 the measurements
with PF.
My stateful NAT64 measurement are as follows.
1. Maximum connection establishment rate test uses a binary search to
find the highest rate, at which all connections can be established
through the statefu
; out. The paper mentions (section A.4) a boost in performance after
> > increasing the state table size limit. Not having looked at the
> > relevant code, so I'm guessing here, but this is a classic indicator
> > of a hashing algorithm falling apart when the table gets close to
>
, but this is a classic indicator
of a hashing algorithm falling apart when the table gets close to
full. Could it be that simple? I need to go digging into the pf
code for a closer look.
Beware, I wrote it about iptables and not PF!
As for iptables, it is really so simple. I have done a deeper
t; threshold, the machines start getting cranky. At 200K+ performance
> visibly degrades, often leading to a complete lockup of the network
> stack, or a spontaneous reboot.
...
> Our pf settings are pretty simple:
>
> set optimization normal
> set ruleset-optimization bas
On Thu, Aug 24, 2023 at 2:57 PM Gabor LENCSE wrote:
> I used OpenBSD 7.1 PF during stateful NAT64 benchmarking measurements
> from 400,000 to 40,000,000 states. (Of course, its connection setup and
> packet forwarding performance degraded with the number of states, but
> the
le? I need to go digging into the pf
code for a closer look.
You also describe how the performance degrades over time. This
exactly matches the behaviour we see. Could the fix be as simple
as cranking 'set limit states' up to, say, two milltion? There is
one way to find out ... :-)
--lyndon
Hi,
But my immediate (and only -- please do NOT start a bikeshed on
ruleset design!) question is:
Is there a practical limit on the number of states pf can handle?
I used OpenBSD 7.1 PF during stateful NAT64 benchmarking measurements
from 400,000 to 40,000,000 states. (Of course
% spin, 6.8% intr, 91.8% idle
Memory: Real: 110M/1722M act/tot Free: 60G Cache: 851M Swap: 0K/21G
Our pf settings are pretty simple:
set optimization normal
set ruleset-optimization basic
set limit states 40
set limit src-nodes 10
set loginterface none
set skip on lo
set
(Sorry, I just realized I replied to just your email address, replying
again to the mailing list this time.)
On 2023年08月16日 10:05, Stuart Henderson wrote:
> wireguard-tools is not required, everything you need for wg(4) is in
> the base OS.
Oh, I didn't know that.
In that case, valid point.
>
Hi,
I appreciate the valuable advices you provided about pf rules in
OpenBSD. I am currently away on a trip, but once I return, I will
thoroughly test those rules and provide you with feedback.
On Wed, Aug 16, 2023 at 3:50 PM Stuart Henderson
wrote:
>
> On 2023-08-14, SOUBHEEK NATH
line takes
>precedence and allows access to ports 22 and 80 for the machine with
>IP address 10.0.8.3.
This also blocks forwarded traffic from machines on wg0 (other than
10.0.8.3) to port 22/80 on the internet, not just to the machine running
PF. If this is what you want, t
from any to any port {22 80}
[ snip ]
I. I use the word "quick" in the first line to prevent the "block"
rules in the second line from taking precedence over it.
In general I prefer in my pf ruleset to block first and then explicitly
allow things through. I find
Hello,
The solution you both provided, worked well.
1. I do not use nano! I use the vi editor for my tasks.
2. Please have a look at the configuration I have implemented.
pass in quick on wg0 proto tcp from 10.0.8.3/32 to any port {22 80}
block in on wg0 proto tcp from any to any
On 2023年08月13日 12:17, Stuart Henderson wrote:
> >https://www.vultr.com/docs/install-wireguard-vpn-server-on-openbsd-7-0/
>
> what a mess of things from the base OS and unneeded third-party tools.
>
List of tools:
wireguard-tools (required), nano (vim would have been enough), and the
rest is
evices are connected to it.
> 4. The wireless router is currently using its default settings to
> assign IP addresses to three other devices that are connected to it.
>You are correct, with this setup and pf rule, the wireguard VPN
>server is accessible from within the lo
>Based on my understanding of the OpenBSD PF-Packet filtering document
>(https://www.openbsd.org/faq/pf/filter.html), the intention of this
>pf rule is to allow only the IP address 10.0.8.4 to access ports 22
>and 80. However, currently both machines with IP addres
default settings and three other
devices are connected to it.
4. The wireless router is currently using its default settings to
assign IP addresses to three other devices that are connected to it.
You are correct, with this setup and pf rule, the wireguard VPN
server is accessible from
BHEEK NATH wrote:
> > Dear OpenBSD Mailing List Community,
> >
> > I hope this email finds you well. I am writing to seek your expertise
> > and guidance regarding a Wireguard VPN configuration and pf rules on my
> > OpenBSD 7.3 system. I have successfully set
s):
wg genpsk > preshared.key
On 2023年08月12日 20:30, SOUBHEEK NATH wrote:
> Dear OpenBSD Mailing List Community,
>
> I hope this email finds you well. I am writing to seek your expertise
> and guidance regarding a Wireguard VPN configuration and pf rules on my
> OpenBSD 7.3 sys
Dear OpenBSD Mailing List Community,
I hope this email finds you well. I am writing to seek your expertise
and guidance regarding a Wireguard VPN configuration and pf rules on my
OpenBSD 7.3 system. I have successfully set up a Wireguard VPN using
the provided interface configuration, and the VPN
pf+carp machines, "pass quick proto
> > {carp, ospf} keep state (no-sync) set prio 7"
>
> That's very interesting, I never realized there was a simple priority system
> ready to use in PF without the need of setting up any queues. Probably the
> "set prio 7&qu
was a simple priority system
ready to use in PF without the need of setting up any queues. Probably the "set
prio 7" option on OSPF+CARP pass rules will juts do the trick and I will
definitely also implement this.
> DNS server software is written with this type of traffic in
Hi,
Are you already using your DNS server's response rate limiting features?
Not yet, as I still believe I should stop as much as possible such traffic at
the firewall before it even reaches the network behind my firewall. So at the
software/daemon/service level it would be my last line of
On 2023/07/19 19:54, mabi wrote:
> --- Original Message ---
> On Wednesday, July 19th, 2023 at 9:32 PM, Stuart Henderson
> wrote:
>
> > If PF is struggling as it is, there's a good chance it will buckle
> > completely if it has to do source tracking too
>
--- Original Message ---
On Wednesday, July 19th, 2023 at 9:32 PM, Stuart Henderson
wrote:
> If PF is struggling as it is, there's a good chance it will buckle
> completely if it has to do source tracking too
That is also something I thought might be the case :|
> Did yo
nresponsive or has a high packet loss because there is over 2 million
> states in the PF states table during the attack. So in my specific case
> I don't care that cloudflare or other external DNS servers can not query
> my DNS authoritative servers for a few seconds or minutes but I do care
>
ind my OpenBSD firewall I have two authoritative DNS servers and
because of recent DDoS originating from >12k IPs against UDP port 53 on these
two servers the whole network behind the firewall gets unresponsive or has a
high packet loss because there is over 2 million states in the PF states tabl
alongside load-balancing you might
> want "mode source-hash" rather than the default round-robin or one of
> the random options.
>
> (I wouldn't recommend sticky-address, because then you get into more
> complex paths inside PF because it has to maintain source-tracking
> in
On 2023-07-19, mabi wrote:
> --- Original Message ---
> On Tuesday, July 18th, 2023 at 10:59 PM, Stuart Henderson
> wrote:
>
>
>> PF's state-tracking options are only for TCP. (Blocking an IP
>> based on number of connections from easily spoofed UDP is a good
>> way to let third parties
1 - 100 of 6743 matches
Mail list logo
