Hi all! I’ve been banging my head against a wall for the last few days creating, removing, updating, changing, everything I could touch around Wireguard. New keys, new tunnels, new IP ranges, using an interface and NOT using an interface… I’ve followed Tom’s tutorials, docs from WunderTech, iVPN and Mullvad VPN guides, and obviously the docs from NetGate. No matter what I tried, I could never get any handshakes to go through from any peer I setup (iPhones, AWS servers, Ubuntu laptop using phone hotspot, etc). It was like Wireguard was not listening on the firewall… I confirmed everything was started in the pfSense UI and even check to see if it was listening on port 51820 via netstat (it was)…
I then stumbled on a post from @dglacey where they said they had to create the firewall rule from the NAT Port Forward page, not the Firewall Rules page…
BINGO! Everything worked. And just like @dglacey, the WAN firewall rule looked the same as every other time I created it before. The only difference was that I created it from the NAT Port Forward page instead of the Rules page…
pfSense+ 23.09
Wireguard 0.2.1
As it’s been two years since that post and the solution worked, I don’t think it’s a version issue around pfSense or WireGuard, but rather some peculiar about my config (and apparently @dglacey’s as well). I can post details about my pfSense config here if someone thinks it will shine some light on my issue, but as this is just supposed to be sitting on the firewall and only the WAN and WireGuard configs are touched, I don’t want to (just yet) muddy the waters any more than they are already…
So… If there’s a general answer, can anyone help me to understand why it had to be setup this way? What is special about creating a firewall rule from the NAT Port Forward screen in pfSense? I mean in this case it is literally port forwarding WAN Address:51820 to WAN Address:51820 so I’m strugling to see why it is needed at all. And the WAN firewall rule that was auto generated is identical to the ones I was manually creating before minus the auto generated description with “NAT” in it… I know from Tom’s video that you don’t have to create it this way, but I’m really puzzled why I (and @dglacey) did to get wireguard working.
This is where Tailscale MESH VPN excels. No port forward required, will traverse any level of NAT, including CGNAT, free tier for up to 100 nodes, uses existing identity managers, clients for every OS, works automagically. Even a primate can set it up.
This is because the firewall (packet filter) and NAT are two separate things, and both need to be configured accordingly.
In the firewall, you need to allow traffic from the WAN port to the IP address where the local service is running.
In NAT, you need to set up a port forwarding rule that translates the public IP/port on the WAN side to the internal IP/port on which the service you want to expose is listening.
So the best way to set up both things in one step is to set a port forwarding rule in the NAT settings, which then automatically creates a corresponding firewall rule (unless you unselect ‘Add associated filter rule’ in ‘Filter rule association’).
If you do it the other way round and just create a firewall rule manually, no NAT rule will be automatically created and therefore no network address translation and no port mapping will take place, i.e. traffic will not be redirected to the internal IP address/port.
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.
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?
Oh shoot… should have taken the time to reread and reflect before posting. You’re right of course!
Perhaps some option was configured differently in the automatically created rule than in the manually created rule? Other than that I have no idea, and again you are right, I definitely have no port forwarding rule for Wireguard on my pfsense and I can connect just fine.
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…
You’re right of course!