But OP says he is using the Wireguard implementation on pfSense. It will directly bind to the WAN IP address, therefore usually (hence the question) no port forward is necessary for this to work.
Bingo! In Tom’s guide, even though he used 172.16.16.0 for the WireGuard network, he had the rule right on the WAN and didn’t have to NAT the WAN traffic to the WireGuard rule…
It would be helpful to know whether the handshake already fails on the way to the pfSense peer or whether it fails on the way back, i.e. if you enable logging on the respective WAN rule and try to handshake, does it show up in the logs?
Do you by any chance have multiple WAN connections?
They failed on the way in to pfSense peer. I enabled logging on the WAN firewall rule to allow traffic in on port 51820 but nothing ever appeared in the firewall System Logs. It’s what lead me down the road of trying to figure out if the service was listening because I didn’t see any traffic even when I probed the port from the outside. Single WAN connection. What makes it more confusing (and why I posted) is that as soon as I created the rule via the NAT screen, the logs lit up with activity so I’m still in the dark on this one…
I definitely have no port forwarding rule for Wireguard on my pfsense and I can connect just fine.
@bb77 This is exactly why I asked… For some reason, I needed it and want to figure out why. 
FWIW, I don’t think this has any impact, but disabling pfBlockerNG didn’t help. I didn’t go as far as removing it entirely, but as I’m only blocking IP’s outside of North America, I shouldn’t have had any issue with traffic coming in from AWS (VA) or AT&T (via iPhone, coming out of GA). I’m bringing this up as I’ve seen videos of strange blocking, missing traffic from logs, when people deep dive and sometimes it’s pfBlocker doing some voodoo…