Date: Fri, 4 Jun 2021 10:03:00 -0700 From: Doug Hardie <bc979@lafn.org> To: Pete French <petefrench@ingresso.co.uk> Cc: stable@freebsd.org Subject: Re: pf starts blocking all traffic after a short while Message-ID: <B8219F01-CA23-4003-B96A-233BAFFF0246@sermon-archive.info> In-Reply-To: <f70dbbd8cec0ea0f2490ff6842c94975@bsdforge.com> References: <E1lp6Mt-000Nhj-V7@dilbert.ingresso.co.uk> <f70dbbd8cec0ea0f2490ff6842c94975@bsdforge.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 4 June 2021, at 09:43, Chris <bsd-lists@bsdforge.com> wrote: >=20 > 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. >=20 What IP address is the client you SSH from using? I get the impression = that it is not one of the private IP addresses listed in the rules. If = that is the case, there is no rule for incoming SSH from public IPs. = Hence, the default block all will apply. I suspect you need another = rule like "pass in quick port 22 all keep state". I understand "keep = state" is the default and doesn't need to be included on each rule. -- Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B8219F01-CA23-4003-B96A-233BAFFF0246>