On Tue, May 04, 2021 at 05:01:35PM +0200, Florian Obser wrote:
> On 2021-05-04 16:50 +02, Sebastien Marie <[email protected]> wrote:
> > On Tue, May 04, 2021 at 02:15:05PM +0200, Alexandr Nedvedicky wrote:
> >> Hello Sebastien,
> >>
> >> thank you for additional info about previously working kernel.
> >>
> >> it looks like your older kernel, which works, might be running without
> >> my commit
> >>
> >> revision 1.1116
> >> date: 2021/04/27 09:38:29; author: sashan; state: Exp;\
> >> lines: +14 -6; commitid: 3W1fRTkLb3ZlUanF;
> >> pf_state_key_link_reverse() is prone to race on parallel forwarding
> >>
> >> we need to adjust assertions. at time we call
> >> pf_state_key_link_reverse()
> >> is state_key either linked to correct reverse peer or not linked at
> >> all.
> >> The pf_state_key_link_reverse() is being called as a reader ons
> >> tate_lock.
> >> There might be more packets, which try to update the state key.
> >>
> >> OK bluhm@
> >>
> >> > # cat /etc/pf.conf
> >> > # See pf.conf(5) and /etc/examples/pf.conf
> >> > #
> >> > # avoid skip on lo to get tryton redir
> >> > #set skip on lo
> >> >
> >> > block return # block stateless traffic
> >> > pass # establish keep-state
> >> >
> >> > # redir 80 -> 8000
> >> > pass in proto tcp to (self) port 80 rdr-to
> >> > 2001:41d0:fe39:c05c:56b8:d15b:2e0a:8775 port 8000
> >> >
> >>
> >> the rule above is also interesting bit. this may trigger NAT-64.
> >> I'm not using IPv6 on my hosts/routers. I'll try to use similar rule
> >> to try to reproduce the crash.
> >
> > I will first try with another rule:
> >
> > pass in inet6 proto tcp to (self) port 80 rdr-to
> > 2001:41d0:fe39:c05c:56b8:d15b:2e0a:8775 port 8000
> >
> > to avoid the possible NAT-64.
>
> fwiw I intentionally run NAT64 and I don't see this.
> But I only have one client, my android phone.
>
> kern.version=OpenBSD 6.9-current (GENERIC.MP) #559: Fri Apr 30 03:31:48 MDT
> 2021
>
>
> set skip on lo
> block return # block stateless traffic
> pass # establish keep-state
> pass in log on vlan64 inet6 from any to 64:ff9b::/96 af-to inet \
> from 192.168.178.23
>
>
indeed, NAT and NAT-64 are essentially same from state table point of view.
it looks like the issue is rather triggered by local-bound traffic, which
matches rdr-to rule. We might be missing a reference when linking a state
key to pcb bound to local socket. This is where I'm currently looking at.
thanks and
regards
sashan
