Got this working by enabling split tunnel in p1 settings and adding a second tunnel entry with the Wireguard subnet as remote. Not sure if this is the best way but it works. If anyone knows a better way please let me know. Thanks

Upgrade to 2.6 or delete WG, setup the right Branche and install WG again.

SOLVED All I had to do at the remote site was change the allowed IP's to 0.0.0.0/0 in the peer, then change the LAN "allow all" rule to the gateway to the wireguard vpn.

Problem solved. Due to WireGuard tunnel closing down. Remote ovpn does not re-active it. I made the wireguard tunnel persistent and the routing works.

Well. I reply myself. As @cmcdonald (developer of the wireguard package so someone to listen to) says in a reply to another post (https://forum.netgate.com/topic/164360/wireguard-site-to-site-issues/13): The only way to force WireGuard out a particular interface currently is to create a static host route (i.e. a /32 or /128 route pointing at the remote WireGuard peer endpoint IP) out a particular gateway. I stick my hope on the word 'currently': Even this being the actual state of the product it would be great if there were some way to manually bind a WG VPN to a given interface. There are cases where setting up a route to achieve that automatic binding is not possible (like my case where the remote endpoint is the same for both tunnels). This is already allowed both in openVPN and IPSec VPNs so it should also be a good thing that WG also had the option. So I beg the developers, if they are monitoring this forum, to add this GREAT enhancement to an other way outstanding product. Thanks for your time and effort.

@jdangjohnny I am going to get myself a $50.00 beer. It was my mistake... On the TUNNEL settings, I need to do a /24 and /not 32 and voila.. Hasta LaVista Baby? It is all working now. I made the right decision to come back with PFSENSE. Now, more tunnels to test it.

@sensewolf Have you tried doing a packet capture on the server from pfsense (Diagnostics/Packet Capture)? Ping the server while the capture is running. What does the capture show? Is the ping getting to the server? Is the server responding to the ping? If so what IP address is it sending its response to? Do you see any states created between your client and the server?

You'd probably get better help posting on an OpenWRT forum about your issue. This is a support forum for pfSense.

@swemattias Yes, multiple peers with the same goal / security rules = 1 tunnel, x peers I shall advise multiple tunnels only when you have different populations of peers (let's say internal users, external users or customers, etc.) Have a nice day !

@packetpirate Thanks for the reply. I use the DNS resolver with Unbound. I looked further into the issue I have and it turns out that one wg connection seems to work just fine but as soon as I configure the loadbalanced mode I have the dns issues. I have no idea why this happens but I'm not willing to put more time in this. I switched to opnsense right now with pretty much the same configuration from the same guy that also posted about the solution to Mullvad's dns hijacking issues and it works completely fine so I'll stick with it for a while.

For anyone else finding this thread. I've found the solution. Create a port forwarding rule INTERFACE: WG0 PORT: 44158 DESTINATION: WG0 DEST PORT: 44158 REDIRECT TARGET IP: MINER IP REDIRECT PORT: 44158 Then everything works as expected.

@jimp said in pfSense 21.05.2-RELEASE and WireGuard 0.1.6: set your update branch to "Previous stable version (21.05.2)" and then install WireGuard 0.1.5_x again. Thanks for the answer I have updated to pfSense Plus 22.01 even before your response.

@dma_pf said in Noob WireGuard Setup Questions: @areckethennu Sorry man, my mistake...on theWwireGuard NAT rule try changing the source to 192.168.1.0/24 and change the value in Destination to Any. I'm confused. I thought that second hybrid Outgoing NAT rule allows the translation of traffic leaving my WireGuard remote devices from the WireGuard interface to my LAN subnet (192.168.1.0/24). Of course, I think the NAT Address on the rule shouldn't be WireGuard Address. It should probably be the LAN subnet. I agree with making the destination any (*). But, I don't understand why I'd want my Source addresses to be from my LAN subnet instead of my from my WireGuard subnet. I'm going to play around with the NAT rules some more. But, I think I'm to the point where Windows is the problem instead of the tunnel. I did find a way to make the WireGuard tunnel a Private one instead of a Public one. Either edit the Windows Registry: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles ```, find the correct network connection by scrolling through them and change "Category" from 0 to 1. Apparently, another way is a PowerShell (admin) command: Set-NetConnectionProfile -InterfaceAlias 'wg0' -NetworkCategory 'Private' where wg0 is whatever it is in Windows. I also went into the Windows Firewall and told it to allow the WireGuard app access to both Public and Private networks. Unfortunately, none of that fixed the problem. I'll see if any NAT rule changes help.

@dma_pf I already did tried to upgrade to pfsense 2.6.0 and pfsense+ , but they have more problem. vlan cant get ip on the wans only ipgateway no ip on wans. also the captive portal is blocking ping and other traffic. so I reverted back to 2.5.2 wireguard was working before. I have solve the problem. I installed 2.5.0 first then upgraded to 2.5.2 and then installed wireguard. Now its working fine.

Just to end this: appliance B was updated smooth and successfully from 21.05.2 to 22.01. All services running. Regards