Date: Fri, 04 Jun 2021 09:43:02 -0700 From: Chris <bsd-lists@bsdforge.com> To: Pete French <petefrench@ingresso.co.uk> Cc: stable@freebsd.org Subject: Re: pf starts blocking all traffic after a short while Message-ID: <f70dbbd8cec0ea0f2490ff6842c94975@bsdforge.com> In-Reply-To: <E1lp6Mt-000Nhj-V7@dilbert.ingresso.co.uk> References: <E1lp6Mt-000Nhj-V7@dilbert.ingresso.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-06-04 02:43, Pete French wrote: > I thought I understood pf pretty well, but this one puzzles me. > I have a very simple setup here - a machine I omnly want to allow > public IPv6 in from one place, allow private Ipv4 from its local > neighbours, and be able to connect out to anywhere. > > Seems to work, I boot it up, I can ssh in. After about five > minutes it just starts blocking all traffic. I have serial > console access, so I can still examine the machine, and if, when > it is stuck, I load a pf config files which allows everything, then > traffic resumesd again, which is what makes me think pf is doing this. > > Heres the rules, all eleven of them... > > root@joanna-may:~ # pfctl -s rules > scrub all max-mss 1200 fragment reassemble > block return all > pass quick proto icmp all keep state > pass quick proto ipv6-icmp all keep state > pass in inet from 127.0.0.0/8 to any flags S/SA keep state > pass in inet from 192.168.0.0/16 to any flags S/SA keep state > pass in inet from 172.16.0.0/12 to any flags S/SA keep state > pass in inet from 10.0.0.0/8 to any flags S/SA keep state > pass in inet6 from 2001:470:6cc4::/48 to any flags S/SA keep state > pass in inet6 from 2001:470:1f08:1771::2 to any flags S/SA keep state > pass out all flags S/SA keep state > > Nothing particularly controversial there I think! > > I've checked the states table, theres a handful in there, and they look > fine. > If I ssh in and run top, then that connection eventually drops when the > packet > flow ceases. The pf table is left with a state of TIME_WAIT in it. > > Any ideas ? This is a mchine inside AWS, so not real hardware, but that > should not make a difference I think... Its also the only time I have used > pf > without using NAT, so maybe I have issed something, but really, this was > supposd to be a very simple ruleset to do a very simple job. OK I may be completely off the mark here. But I seem to remember something about potential problems with fragment reassembly on IPv6. Just for kicks, does the problem still manifest if you comment scrub all max-mss 1200 fragment reassemble Again, I may be off the mark here, as I don't exactly remember where/when I read about it. But just thought I'd throw it out there in case it helped. --Chris > > -pete.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f70dbbd8cec0ea0f2490ff6842c94975>