Turns out I had missed yet another piece of the tutorial. It asked to set interface group membership to only unassigned tunnels and then says to apply the firewall rule to the individual interfaces not the WireGuard interface group. I had set them to not be in the group but then still set my allow all rule on the group and not the individual interface! Once I fixed that error everything seems to be talking as it should. Hopefully my stupidity helps someone else googling the same problem years from now.

@tomasenskede

This is what I am trying to setup

e66b3dcd-b006-4bca-959b-bc4898ebda47-image.png

@hspindel Yes, on all my boxes actually there are VPNs active, including in production mission critical environments, in fact some have like 30 VPNs setup, some WG, some IPsec, etc..... so I don't really think it was related to that. Either way though glad it's working as expected now!

@franta correct.

My use-case is Site-to-Site VPN where I have added networks later on and did forget to change the allowed IPs in the configuration. And this happened to me more than once. 😉
And pfSense itself is not using those allowed IPs for its routing so right now I am using this on a tunnel on both ends. I like the freedom of not having to touch this tunnel ever again.

@paoloposo If you are referring to System>Routing and creating Gateway and Static Route for Wireguard network, yes I did.
One portion of information I forgot to mention was when I do a IP scan from remote office to main office over the wireguard tunnel. I am able to see three internal IP address on main office network and that is it.
One IP is our Global Protect IP that is NAT to internal to external, second IP is the pfsense Box LAN IP address and third IP is Dell Equal Logic SAN internal.

@Bob-Dig Yes, only 1 wg-client, and 2 openvpn-clients.
As per the MTU value of 1320, I know it's not optimal, but that is the default MTU proposed by my provider (AirVPN), and was "good enough" to highlight the issue and narrow the possible cause (didn't want to mess with too many parameters): better have a MTU that is too low than too high, as far as I understand.
Once I get a solution or workaround, it will certainly start playing with the values to optimize my bandwidth and will certainly come to set it at 1420.

@Bob-Dig & @paoloposo
I have entertained the idea that DNS might need to be configured specifically for Wireguard (hence my post here), but somehow my googling always went off in different directions. And this has been going on for two weeks. I tried so many solutions both software and hardware, but somehow it completely escaped me that there even is a DNS field in the Wireguard app for Android.

I feel embarrassed for having bothered the community with such a simple matter, but am grateful that both of you stepped in to help out.

Thanks!

@hspindel

Update, finally got the VPN tunnel to work!

I can only access the NAS which is in another network

@Bronko

Ah yes, I forgot to post a link to the reddit thread as well. Thank you! 😃

@Bronko said in Port forwarding through WG tunnel missing reply-to:

Ok, but @carrnelltech have the right ideas already included at bug report.

Yes, agree, he elaborated this bug report very well. Similar as the interface config page for OpenVPN, there could be some different options if you have assigned a Wireguard instance as network port.

Gotcha, well it's not really feasible to say give a VPN client a local IP on a subnet the firewall is already managing as an interface, so I think the only solution would be to use NAT but this can create it's own issues.

But if you were to NAT the wireguard connection to a different IP within that local LAN subnet (and make sure it's not one within that subnets DHCP pool) then you probably can achieve what you're looking for here.

@JuntaSense thank you so much - this did it!

@Owen82 They both should be in it.

Remove any rules you have except allow anything for testing. And set keep alive with 25 seconds for testing. Set a port in the VPS as well.

SNORT!!!