On Thu, Jul 20, 2023 at 05:52:07PM +, mabi wrote:
> --- Original Message ---
> On Wednesday, July 19th, 2023 at 10:58 PM, Stuart Henderson
> wrote:
>
> > For rules that pass traffic to your authoritative DNS servers,
> > I don't think you need much longer than the time taken to
--- Original Message ---
On Wednesday, July 19th, 2023 at 10:58 PM, Stuart Henderson
wrote:
> For rules that pass traffic to your authoritative DNS servers,
> I don't think you need much longer than the time taken to answer a
> query. So could be quite a bit less.
Right good point, I
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
>
> That is also something I
--- 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 you already
On 2023/07/19 19:13, mabi wrote:
> --- Original Message ---
> On Wednesday, July 19th, 2023 at 12:40 PM, Stuart Henderson
> wrote:
>
> > I don't think you understood what I wrote then - they are the
> > opposite of helpful here.
>
> No, I do understand what you wrote but I should have
--- Original Message ---
On Wednesday, July 19th, 2023 at 12:40 PM, Stuart Henderson
wrote:
> I don't think you understood what I wrote then - they are the
> opposite of helpful here.
No, I do understand what you wrote but I should have explained my case in more
details. Behind my
On 19/07/2023 13:31, Stuart Henderson wrote:
> On 2023-07-19, Kapetanakis Giannis wrote:
>> Maybe even better, can it run under relayd (redirect) on top of carp?
> That's just rdr-to behind the scenes, no problem with that, though if
> you want to do per IP rate limiting alongside
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
On 2023-07-19, Kapetanakis Giannis wrote:
> On 18/07/2023 23:59, 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 prevent your machine from communicating
>> with
--- 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 prevent your machine from
On 18/07/2023 23:59, 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 prevent your machine from communicating
> with IPs that may well get in the way i.e. trigger a
On 2023-07-18, mabi wrote:
> Hello,
>
> From the following documentation, I am trying to figure out which PF tracking
> options are also valid for UDP but unfortunately it is not quite clear to me:
>
> https://man.openbsd.org/pf.conf.5#Stateful_Tracking_Options
>
> My goal would be to do add
Hello,
>From the following documentation, I am trying to figure out which PF tracking
>options are also valid for UDP but unfortunately it is not quite clear to me:
https://man.openbsd.org/pf.conf.5#Stateful_Tracking_Options
My goal would be to do add rate limiting options to a PF UDP pass
14 matches
Mail list logo
