@bob-dig said in Strange login from another country: @pastic said in Strange login from another country: I realise something as I write this: are there 'two levels' involved here? The wireguard rule will let everyone through the firewall on the specified port, but having passed the firewall block then the wireguard service will still refuse everyone that does not have the configured keys? Yes. Hard to believe that this is news to you, you are setting up a graylog server, which is advanced stuff in my book. Let's call it a blind spot. :-) I don't work with networks, it's just a hobby. And until this Wireguard 'project' I always had pfsense blocking everything from the outside. And yes, I did struggle a bit setting up graylog, but it was fun. Thanks!

first, try openvpn because that is well established and wire guard is new. the ProtonVPN service website should have setup instructions and OpenVPN config files that you can use.

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

Just want to reply here my discoveries, to save people the hassle of attempting this to find out it does not work, there are two types of GRE tunnels, GRETAP and GRETUN, one supports layer 2 features such as broadcast/multicast and one does not, the PFSense implementation appears to use the later which does not support this feature, please see the following article to show the difference https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels#:~:text=While%20GRE%20tunnels%20operate%20at,header%20in%20the%20inner%20header. You would need a local UDP relay instead (on the client side) to instead allow the client to relay these broadcast message as unicast to a specific host, I struggled with this for Windows File Sharing (WS-Discovery) broadcast packets and ended up resorting to a script that auto maps all network drives on successful client connection, perhaps someone could get this working with a L2TP on top of Wireguard? https://github.com/sparky3387/automapwireguard - Shameless plug of the automap script if someone else also needs this.........

@cmcdonald thank you for the explanation. indeed the problem was my frr configuration, all is working fine now.

So, after some further digging, I discovered a couple things. You have to actually assign the tunnel to an interface The MacOS Wireguard app doesn't support .ddns.net domains Thank you for your help, once I assigned the interface correctly everything worked like a charm.

@bob-dig Yes, I can ping the domain name and receive a response from the firewall.

@stephenw10 I deleted the WireGuard tunnel then I set it up all over again. Done the same thing at VPS. Rebooted remote VM and pfSense and it started working. I have no idea what happened before but I thanks you for all the support you provided!! Thanks a lot :-) kind regards

@johnpoz Thanks - but that gave the same error. I think the root of my problem is that VirginMedia hate VPNs! https://windowsreport.com/vpn-blocked-virgin/ I think I will try accessing the site sometime when on another isp! Thanks again - must go battery very low.

@gabacho4 Did you ever figure it out?

I created a small tool luckman212/stv to help make it a little easier to debug states. In case it's useful to anyone else.

@ma0f97 Has no one an idea?

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 thx for the hint it's working now, it totally make sense now. hope it will you @bbusa as well

@theonemcdonald said in Wireguard Public and Private Key Protection: I have mentally considered an additional layer for the extremely paranoid, but because pfsense already has encrypted configuration backup capabilities, I don't plan on spending much time on this any time soon. Fully agreed.