Not certain I understand, are you saying to create a rule in the WireGuard rule tab or in the VPN rule tab or both? the rule would look like? Action: Pass Interface: Wireguard ? or VPN? Protocol : TCP Source: Alias-VPN Destination: Lan subnet Destination Port Range: From HTTPS(443) to HTTPS(443) Gateway: Opt1GW -VPN Alias-VPN Network: IP Range of remote Office interface (192.168.76.0/24) IP range of WireGuard Interface (10.10.40.0/24) These rules would be replicate (with networks reversed) in the remote PFsense. Please let me know if I'm even remotely going in the right direction. Thanks

@luckman212 Trying for the Dual-Tunnel solution now. The floating rules arent binding the tunnels. :(

Well, interestingly enough, this issue went away with as pfSense reboot. I was having these problems about 1 time per hour before, now it's been 24hrs since the reboot and it hasn't happened a single time. Not sure what was messed up, guessing it was some routing or state table issue, but oh well it seems OK now.

@mrwildbob what pfSense version are you using? And how have you setup Wireguard, are you NAT-ting that traffic on your side? Assuming that your and his network IP range are not the same, e.g. your network is 192.168.100.0/24 and his is 192.168.<not-100>.0/24 it is possible. Right now you can reach the RPi and maybe even other clients on the same network as the RPi but the packages don't find their way back to you. On his network all non-local IPs will be forwarded to the Spectrum router and out into the world. First in Wireguard you have to make sure that your are allowed to access his network range. If you can add routes to the Spectrum router you can add your network with the RPi as the gateway. If you can't add routes then you have to setup NAT on the RPi so that for the rest of the network the traffic looks like coming from the RPi and they will send the answers back to the RPi. And the RPi then knows what to do with the traffic destined for Wireguard.

@luckman212 Thank you for sharing. I wrote the #15554. I see that Netgate has not shown any interest in this proposal.

@sam.newby You need an outbound NAT rule and a LAN rule that directs whatever traffic you want through the tunnel instead of default gateway. I have an alias called VPN_USERS with the IP addresses of those allowed to use the tunnel, and rules that say any traffic bound for 10.10.0.0/16 (company LAN space - don't ask why it's a /16) is routed through the tunnel. Read the Netgate guide I linked to. That's how I configured mine years ago.

Would be helpful if you could provide: IP/subnet details for your "Base LAN" and "Remote LAN" some screenshots of those interface rules screenshot of Firewall > NAT > Outbound screenshot of System > Routing > Static Routes

Can be xplained with : with no firewall rules whatsoever : [image: 1767957636235-3015b3fb-2a1e-4bc7-a765-a3341327f725-image.png] DHCP traffic will work ** - and nothing else. ** because DHCP traffic has 'pass' rules for this interface, they are not shown in the GUI )

@luckman212 said in wireguard - dpinger packet loss on monitor ip: @nobanzai Sorry where did you ever say you had 2 ISPs? Again that's why I was asking you to give more details and draw a diagram. I just re-read the entire thread and the only public IP block I see mentioned is 193.175.24.0/24 which seems to belong to KNF, Kommunikationsnetz Franken e.V. Sorry, I was just about to update my network documentation and diagrams when I saw the post mentioned above. Instead of finishing the documentation, I changed the port number, and everything worked. However, updating the entire network and routing structure in the documentation takes time. Please bear with me. It will definitely be finished by the next question here.

@mfld Yep here's the commit in case anyone wants to review the change https://github.com/pfsense/FreeBSD-ports/commit/2ad4d245c30b2543e9661c00d497a72624062611

Still happening at 2025-12-31 5:39 PM (MST). In both pfSense Version 2.7.2-RELEASE (amd64) and Version 2.8.1-RELEASE (amd64).

Learned about AmneziaWG yesterday, this needs to be an option imho. Hope someone picks this up.

@pfguy2018 I doubt that this will work but interesting, that this seems to be an option?

@joetaber said in Wireguard should check that the peer public key is different from the tunnel public key: @tinfoilmatt Thanks, I closed that PR and reopened it here: https://github.com/pfsense/FreeBSD-ports/pull/1433 Thanks, we will pull this in soon

@McMurphy Without seeing the rest of your config, what comes to mind is: mismatched pub/priv keys on one side of the WG1006 tun overlapping (conflicting) subnets causing routing ambiguity: check subnet and mask of all peers to make sure they make sense and are explicit

@MartynK searching through this forum: "PIA using pfSense WireGuard Package", post from mid 2024: https://forum.netgate.com/post/1157847 Or on the Lawrence Systems forum (I think it's about the same but with more posts): https://forums.lawrencesystems.com/t/pfsense-pia-vpn-wireguard/19376/7 Basically, use PIAs manual-connect repo (or someone's who made one for pfSense specifically) to get a regular Wireguard conf. https://github.com/pia-foss/manual-connections to

@4o4rh Give it a try, as long as you don't use their DNS-Servers. And try that with the second tunnel as well. But again, there are problems with ProtonVPN and more tunnels. But that is not a general policy routing problem, it is specific to some Privacy-VPNs, I am with you on that.

@jlinesabi Just as an update.. my system right now is on failover behind CGNAT (static side) and connected to a site behind an AT&T Wireless site with a public IP but set up for dynamic. Working quite well.