Date: Thu, 14 Sep 2023 11:28:11 +0100 From: Kristof Provost <kp@FreeBSD.org> To: d@delphij.net Cc: freeBSD-net@FreeBSD.org Subject: Re: Regression with pf or IPv6 on FreeBSD 14 with IPsec gif(4) tunnel Message-ID: <0DA172FD-8E4E-4DA5-A55E-8470A8EEF878@FreeBSD.org> In-Reply-To: <8a063059-d3be-1dd5-d89d-d0054ee269cd@delphij.net> References: <8a063059-d3be-1dd5-d89d-d0054ee269cd@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 Sep 2023, at 4:54, Xin Li wrote: > Hi! > > I recently upgraded my home router and found that there is some regress= ion related to pf or IPv6. > > When attempting to connect an IPv6 TCP service, process would enter a s= eemingly unkillable state (the stack varies but always begins with write,= so it seems that tailscale was trying to send some packet to the server)= , until racoon is killed and restarted (at which point the connection wou= ld be dropped). > > tcpdump over the gif(4) channel captured a lot of seemingly duplicated = packets like this: > > 03:40:50.088262 IP6 LOCAL.16275 > REMOTE.443: Flags [.], seq 1619:2947,= ack 4225, win 129, options [nop,nop,TS val 2817088580 ecr 3077807235], l= ength 1328 > 03:40:50.088332 IP6 LOCAL.16275 > REMOTE.443: Flags [.], seq 1619:2947,= ack 4225, win 129, options [nop,nop,TS val 2817088581 ecr 3077807235], l= ength 1328 > [identical except timestamp] > 03:40:50.089107 IP6 LOCAL.16275 > REMOTE.443: Flags [.], seq 1619:2947,= ack 4225, win 129, options [nop,nop,TS val 2817088581 ecr 3077807235], l= ength 1328 > > Am I the only person who is seeing this? (Admittedly my setup is somew= hat unique; my home ISP doesn't provide IPv6 service, so I have a gif(4) = tunnel to my datacenter, which connects to Hurricane Electric's IPv6 tunn= el service and basically routes my IPv6 traffic to that tunnel. Earlier = I discovered that some IPv6 connectivity issues were related to MTU being= too big (1480; reduced to 1400 now) but the unkillable IPv6 applications= was new and only happened on 14.x) > That doesn=E2=80=99t immediately ring any bells, no. Are you using route-to anywhere? There=E2=80=99s been a change (829a69db8= 55b48ff7e8242b95e193a0783c489d9) that has some potential to affect uncomm= on setups, but right now I=E2=80=99m just guessing. I=E2=80=99d recommend tcpdump-ing the wan link at the same time as the gi= f tunnel so you can work out if the packets are being dropped locally or = remotely. Or you can try adding =E2=80=98log=E2=80=99 statements to the p= f rules and using pflog to figure out if/why packets are being dropped. Best regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0DA172FD-8E4E-4DA5-A55E-8470A8EEF878>