On 14 Oct 2020, at 21:35, J David wrote:
On Wed, Oct 14, 2020 at 3:20 PM Kristof Provost
wrote:
I’ve not dug very deep yet, but I wonder if we shouldn’t have to
teach pf to change the source port to avoid conflicting states in the
first place.
That was my first thought as well, framed
On Wed, Oct 14, 2020 at 3:20 PM Kristof Provost wrote:
> I’ve not dug very deep yet, but I wonder if we shouldn’t have to
> teach pf to change the source port to avoid conflicting states in the
> first place.
That was my first thought as well, framed mentally as some sort of
port-only
On 14 Oct 2020, at 21:16, J David wrote:
On Wed, Oct 14, 2020 at 1:59 PM Kristof Provost
wrote:
There’s good reason to do this, as we have to be able to match
state
on both the pre-translation side (when processing LAN -> WAN traffic)
and post-translation (WAN -> LAN).
So, basically, pf
On Wed, Oct 14, 2020 at 1:59 PM Kristof Provost wrote:
> There’s good reason to do this, as we have to be able to match state
> on both the pre-translation side (when processing LAN -> WAN traffic)
> and post-translation (WAN -> LAN).
So, basically, pf would need separate states for each
On 14 Oct 2020, at 18:52, J David wrote:
On 12 Oct 2020, at 23:48, Andreas Longwitz wrote:
pf gives this messages in debug mode (pfctl -x loud).
Yes, with that setting I'm also seeing those messages.
On Tue, Oct 13, 2020 at 5:35 PM Kristof Provost
wrote:
I see the same ‘stack key attach
On 12 Oct 2020, at 23:48, Andreas Longwitz wrote:
> pf gives this messages in debug mode (pfctl -x loud).
Yes, with that setting I'm also seeing those messages.
On Tue, Oct 13, 2020 at 5:35 PM Kristof Provost wrote:
> I see the same ‘stack key attach failed’ error message. My current
> thinking
On 12 Oct 2020, at 23:48, Andreas Longwitz wrote:
Hello,
now I can confirm (on FreeBSD 10 Stable) what you see on fb2 when your
program udp_client is running on fb1. pf creates a state for the first
packet only, for the other packets pf failes to create a state with
messages like
pf: stack key
Hello,
now I can confirm (on FreeBSD 10 Stable) what you see on fb2 when your
program udp_client is running on fb1. pf creates a state for the first
packet only, for the other packets pf failes to create a state with
messages like
pf: stack key attach failed on re0: UDP in wire:
On Sun, Oct 11, 2020 at 12:46 PM Andreas Longwitz wrote:
> Please look at the output of "pfctl -vsn" on fb2 during your test.
> With "netstat -ss | grep drop" you can check for packets dropped by the
> kernel for what reason ever.
Here's the complete diff of the output from netstat -ss from
> To investigate this issue, I've created a greatly simplified and
> reproducible test case. The code is available at:
>
> https://github.com/jdavidlists/pfudpbug
A similar setup works for me without any problems, so there may be
something special in your environment.
Please look at the output
To investigate this issue, I've created a greatly simplified and
reproducible test case. The code is available at:
https://github.com/jdavidlists/pfudpbug
It includes the pf.conf, the source code for client and server, and
the rc.conf from all three machines.
The test uses three FreeBSD
We have pf running on a FreeBSD 11.4 system acting as a load balancer,
mapping a set of 8 external DNS service IP addresses to a set of
internal DNS servers, any of which can handle those requests.
When UDP packets from one source IP/port arrive for multiple external
IPs in a short period of
12 matches
Mail list logo
