@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.

@michmoor When I initially set up the account, I falsely assumed the fiber network would be 300 down, 300 up since it is fiber. I had the same set up at a previous location. Turned out it is actually 300 down, 10 up. As usual, the issue was PEBKAC, as I did not do my due diligence researching the ISPs in the area.

@bob-dig yes, I am now using different listen ports on the 2 mullvad tunnels. Hopefully that resolves the issue.

I find the problem.

In the Wireguard Setting, I need to add the DNS IP in both [Interface]DNS and [Peer]AllowedIPs
Also, I need to add rule to pass the traffic to the Wireguard IP

[Interface]
DNS = 10.1.1.1

[Peer]
AllowedIPs = 192.168.2.20/32, 10.1.1.1/32

@mikegnd98 said in Wireguard using a virtual private provider (IVPN) and LAN access:

which is weird because it doesn't sound that complex.

It is not and what you want should work anyway. You can use a VPN for all your outgoing traffic and still connect with your phone to your own VPN server at home, so not sure what your real problem is.

@frodet Here. There is something already but it is closed for no good reason in hindsight.
Reading the comments, maybe disabling the keepalive helps...

I have the same problem, i did install again pfsense and do it manually and today i did understand that wireguard was the problem.
I had no other option and i remove that package.
Wireguard was messing with my pppoe connection for going up/dpinger sometimes one peer would not work etc etc..uff

@sensewolf

Okay, found the error:

At the remote end, I allow all IPs through the wireguard tunnel. But I incorrectly provided this as 0.0.0.0/24 instead of 0.0.0.0/0. After changing this, the tunnel became stable.