@Ratfink Connecting two sites with Wireguard VPN is absolutely doable, and you don't even need fixed IP's for it to work.
When you say you have 5 fixed IP's from your ISP, I'm kind of assuming you have your office at your house? Meaning they are both connected to the same fibre? Otherwise, if they are at very different locations, is it still the same ISP?
In terms of getting the IP's on the respective pfsense machines, I assume you know how or have instructions from the ISP to do this. Might be MAC based if DHCP for example...
Anyway, running pfsense on repurposed HW is very common and can be done "barebone" or virtualized. So you shouldn't have any problems getting to to work on your rack servers, hopefully.
So step one is of course getting both machines up and running. And since they will be for different sites and connected via VPN you must make sure to use different LAN subnets on them. Like 192.168.1.0/24 on one and 192.168.2.0/24 on the other.
Once you have them up and running you can follow a guide like one of these to set up wireguard.
Even though you have fixed IP's it might be a good idea to get two domains, unless you already have that.
If you want to go over WAN anyway, assign an interface to the wg instance and enable it at site 2. This brings up a new firewall rule tab for it then.
Now go to the "Wireguard" tab, edit the existing rules and change the interface to the new one.
I'm not sure what you mean by your last sentence but, I've done the rest.
You mean, changing the interface in the filter rule?
In Firewall > Rules you will see a tab called "Wireguard". pfSense might have created a rule on this tab automatically, when you set up the Wireguard tunnel.
So go to this tab and edit the existing rule and change the interface from "Wireguard" to the interface, which you have assigned to the Wireguard instance before.
Then the rule disappears from the Wireguard tab and appear on the new interface tab.
Also in the WG settings on router 2 you have to change the "allowed IPs" to 0.0.0.0/0 to accept public forwarded traffic.
The problem was an any/any rule in the Wireguard unasigned tunnel firewall rule list. Even though the AirVPN WG interface was assigned, group rules are evaluated first...
Hope this helps someone else as well.
@FoolCoconut THANK you. ive been trying to figure this out for a very long time.
Yup, those devices are probably not trying to resolve .local addresses using DNS servers at all. They assume they are mDNS and try to find them locally.
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.
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
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.........
