@jarhead Thanks for clarifying that. I guess it's not possible with WireGuard. I know I can do it with OpenVPN, but throughput is not that great.

@bob-dig Thank you very much! I will try that.

@bob-dig the reason I suspect the Realtek LAN driver is tied to WG is due to the fact I didn't change ANY settings other than swapping the interfaces between LAN and WAN. Wireguard tunnels, routing and firewall rules all remained exactly the same as before (when I changed things, I always tried to change 1 thing at a time so I know what each change's effects were). Due to this experience, I just bought another M.2->LAN adapter with Intel chipset this time for my Intel Nuc. I will swap my Realtek adapter (currently running as WAN) and try a few more experiments to see if it had something to do with the m.2->LAN issue or not.

FYI, this issue seems to be resolved in pfSense Plus - I tested it today, after upgrading. So it's "broken" in CE (only)? Thanks!

I was able to get it figured out. WireGuard going through my Netgate XG-1541 even if on the LAN side with router being a UniFi UDM-SE seems much quicker than the UDM-SE providing WireGuard.

@molski You are doing things your own way which is fine, if you know what you are doing, but I have my doubts. It looks to be more trial and error on your side.

@nickologic Why are you using public IP's on you LAN?

I have the same problem. Tried both Safari and Firefox on macOS. I get this error in Safari's console upon clicking Generate: SyntaxError: JSON Parse error: Unrecognized token '/'! [image: 1672422949494-screenshot-2022-12-30-at-19.53.00.png] I get this error in Firefox's console upon clicking Generate: Uncaught SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data! [image: 1672422964746-screenshot-2022-12-30-at-19.55.03.png] I've inspected the JSON response and there was an offending / in the start of the response which makes it invalid: /{"privkey":"...","pubkey":"...","was_clamped":true}

@menethoran Yes, I have used this script to generate a config from the Sydney, Australia server, and It's working fine. However, as PIA does not provide the official method to do this on pfSense, I'm not sure if it will work as reliably as other VPN providers who do offer it. Still, it stayed connected for two days and survived two pfSense reboots, so PIA didn't nuke my generated config just because I got disconnected for a few minutes, which is good.

Sounds like Outbound NAT is missing. https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html#outbound-nat

Is there any update to the potential of having a WireGuard VPN wizard like the OpenVPN wizard with client exports?

@dennism14 Does your home router have a public IP that is it accessible from outside? If he doesn't it won't work with BGP or forwarding naturally. In this case you can only go with VPN.

According Christian McDonald from NetGate in his video "pfSense WireGuard Guide Series 001 - Mullvad Failover" it should start handshaking at this point

@pastic Your WAN IP is reachable by who ever you want. Like your front door. But you need the 'key' from that moment. You have a key. But they : @pastic said in Log for connection attempts?: traffic from another country had been let through pfsense according to the 'pass traffic to wireguard' rule. do not have the key.

@jarhead I am configuring this device for deployment. Sorry I was not clear on that point. That is why the WAN is connected to my LAN. This device will be going over a thousand miles away and I need to set it up before it makes that journey. All of this headache just so I can remotely help (and make my life a little easier without needing to coordinate some kind of remote desktop/access). And this scenario requires the remote device to punch the hole through because their ISP uses private IPs, so the link will rely on the remote device establishing the link. I have isolated it to the Firewall blocking the access. The default deny rule was stepping in to block it. The Firewall knows it is the S2S interface... and not the WAN. Private IP restrictions do not apply. The Default deny rule on both firewalls was blocking access. Oddly, the PC on the remote pfSense had no issues accessing my pfSense WebGUI but could not access my LAN devices... and I could not go the other direction to access the WebGUI of the remote device.. I need to review the syntax/scope on the Firewall rules again. By default, pfSense uses XXX net for Source. I had copied the allow rules to the S2S interface and updated to use S2S net. As Christian's video shows in the Firewall section, source is set to * (All). I have the tunnel working now. So sorry about wasting anyone's time. P.S. Akismet is flagging my post as spam. Not sure why that is. Apparently it won't allow me to add images with the post.

@chudak Don't know what to tell you. For me, it's been fixed for three days now. Maybe 25 seconds is the wrong value for your network? Also, sometimes different problems can have the same symptoms.

Went months without issue then would drop the connection and wouldn't reconnect. I rebooted the pfSense and the MT-1300 and no luck. I rebuilt the VPN's on both sides, changed keys and no luck. Sometimes I'd wait a couple hours and it would connect again for a few hours or as long as 20 hours. I changed the port to 51281 on both sides and it's been up for 2 days.