Regression with pf or IPv6 on FreeBSD 14 with IPsec gif(4) tunnel

From: Xin Li <delphij_at_delphij.net>
Date: Thu, 14 Sep 2023 03:54:34 UTC
Hi!

I recently upgraded my home router and found that there is some 
regression related to pf or IPv6.

When attempting to connect an IPv6 TCP service, process would enter a 
seemingly 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 would 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], 
length 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], 
length 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], 
length 1328

Am I the only person who is seeing this?  (Admittedly my setup is 
somewhat 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 tunnel 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)

Cheers,