WireGuard remote access: handshake completes, no decrypted traffic on tun interface — pfSense 2.8.1, fresh config rebuild, package reinstall

srbol

Setup

Hardware: Protectli FW6A, fresh install pfSense CE 2.8.1-RELEASE (amd64)
WireGuard package: 0.2.9_6
WAN: fiber via DHCP, public dynamic IP
Migrated from FW4B running 2.7.2 where this exact WireGuard setup worked for over a year
All 16 recommended Netgate patches applied
IPv6 fully disabled (Allow IPv6 unchecked, all interface types None)
Other WireGuard tunnel (ProtonVPN client outbound, tun_wg0) works perfectly

WireGuard Remote Access Configuration

Tunnel: tun_wg1, port 51821, assigned to OPT4VPN
OPT4VPN interface: Static IPv4, 172.16.16.1/24, no gateway
Single peer (mobile road warrior, dynamic endpoint), AllowedIPs 172.16.16.10/32
PSK enabled
Client (macOS, Passepartout): Address 172.16.16.2/24, AllowedIPs 0.0.0.0/0, Endpoint <wan>:51821
Firewall: WAN UDP 51821 pass rule, OPT4VPN allow-any rule
Outbound NAT: Hybrid, manual rule for 172.16.16.0/24 -> WAN address
State Policy: Floating (changed from default Interface Bound, no effect)
Firewall logs show no blocks for WireGuard traffic

Symptom

Handshake completes consistently (Status -> WireGuard shows recent handshake timestamp)
Asymmetric byte counts: client TX ~0.4 MB, client RX ~340 B; server TX ~45 KiB, server RX ~1 KiB
Ping from client (172.16.16.2) to pfSense tunnel address (172.16.16.1) times out 100%
Traceroute returns * * * for all hops
nc -u -v <wan>:51821 from client succeeds (UDP path is open)
Same client config works perfectly to a separate WireGuard server (different site, GL.iNet Flint 2)

Diagnostic Evidence
Packet capture on tun_wg1 (Diagnostics -> Packet Capture, filter host 172.16.16.10) while client pings 172.16.16.1: zero packets captured. Capture without filter shows only unrelated outbound traffic from internal hosts hitting the tunnel interface; no inbound decrypted client traffic appears on the tunnel interface despite handshake completion.

This means encrypted WireGuard handshake packets reach pfSense, decrypt successfully, but decrypted client data packets never surface on the assigned tun_wg1 interface for routing.

What I've Tried

Verified routing table (172.16.16.0/24 -> tun_wg1 present)
Verified outbound NAT, firewall rules, WAN port forward
Toggled State Policy from Interface Bound to Floating
Restarted WireGuard service multiple times
Full pfSense reboot (multiple)
Full WireGuard rebuild from scratch: deleted interface assignment, peer, tunnel; recreated all with fresh keypairs and fresh PSK; reassigned interface; recreated firewall rules
Reinstalled the WireGuard package (System -> Package Manager)

All seven attempts produced identical failure mode with identical byte-count asymmetry. The same exact configuration pattern worked flawlessly on FW4B/2.7.2.

Question
Is this a known WireGuard 0.2.9_6 + pfSense 2.8.1 issue with assigned-interface remote access tunnels? Anything specific about the WireGuard kernel module's handling of decrypted ingress packets on assigned interfaces in 2.8.1 that differs from 2.7.2?

srbol

Resolved — operator error.
Peer AllowedIPs was 172.16.16.10/32, client address was 172.16.16.2/24. Mismatch. Changed client to 172.16.16.10/24 and the tunnel passes traffic correctly.
Apologies for the noise.