RST Packets bypass wireguard interface

I've got a 14.3-STABLE / 15-STABLE (behavior under both) with a
wireguard VPN running and assigned to the second routing table. I've
noticed outbound packets being blocked at the firewall (also
14.3-STABLE/15.0-STABLE) with the VPN endpoint address (the private
IP, not public). There is only one application running that uses the
VPN, and it is started by "setfib 1". Most traffic does go to through
the wireguard interface; it's only the RST packets being sent out of
the ethernet interface, and it looks like it is most of them. I've
tested this on two machines and find the same behavior on both.

The RST packet going out the wrong interface on the server (on igc0):
15:49:23.229671 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
TCP (6), length 40) 10.22.x.x > y.y.y.y: Flags [R], cksum 0x1bda
(correct), seq 3561974863, win 0, length 0

And blocked at the firewall:
rule 26/0(match): block out on sfp0: 10.22.x.x.57653 > y.y.y.y.16459:
Flags [R], seq 2027176873, win 0, length 0

Routing table 0:

Internet:
Destination        Gateway            Flags         Netif Expire
default            10.0.0.254         UGS            igc0
10.0.0.0/24        link#1             U              igc0
10.0.0.1           link#3             UHS             lo0
10.22.x.0/24      link#10            U               wg0
10.22.x.x       link#3             UHS             lo0
127.0.0.1          link#3             UH              lo0

Routing tables (fib: 1)

Internet:
Destination        Gateway            Flags         Netif Expire
default            link#10            US              wg0
127.0.0.1          link#3             UH              lo0

PF is disabled on the server, and there is no obvious "cross
pollution" of routing tables. Are there any socket operations or flags
that the application could be using that would result in a packet
going through routing table 0 instead of the one specified with
setfib? Is there some obvious solution to this I'm missing, or should
I file a PR?

Thanks