Date: Wed, 05 Oct 2022 12:11:05 -0700 From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca> To: Kristof Provost <kp@FreeBSD.org> Cc: FreeBSD pf <freebsd-pf@freebsd.org>, Eirik =?utf-8?q?=C3=98verby?= <eirik.overby@modirum.com> Subject: Re: RFC: enabling pf syncookies by default Message-ID: <ba359e391459a275@orthanc.ca> In-Reply-To: <58A14C48-3248-4D41-884C-93190AAFCD2C@FreeBSD.org> References: <BF7E3C1C-CC06-4874-821E-2B3BBDC2F467@FreeBSD.org> <ba35872719a2d75e@orthanc.ca> <58A14C48-3248-4D41-884C-93190AAFCD2C@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kristof Provost writes: > That=E2=80=99s not ready to go in, because the bug it tests for isn=E2=80= > =99t fixed yet. I hope to port the openbsd fix tomorrow, but it=E2=80=99s= > the sort of thing that needs an hour or two of concentration, so .. mayb= > e, maybe not. Something to watch out for ... Henning's fix might not have completely solved the problem. A few weeks ago we deployed the "fixed" pf code into production. When we enabled global syncookies we immediately started receiving reports from customers about hung connections -- the same problem that motivated the initial fix. The customer complaints are predominantely coming from folks who enable Apple's Private Relay service. Private Relay tries hard to preserve your network geolocation, so they re-map addresses into small chunks of address space that originate from the same geographical location as the client. And that provokes the address:port reuse behaviour that first triggered the bug. In the short term we had to disable syncookies to get our customers back online. Right now I'm working on shuffling together enough hardware so we can try to reproduce the problem inhouse, and continue chasing down the bug. --lyndon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ba359e391459a275>