WireGuard lives!

cmcdonald

except forgetting to add firewall rule on the interface which is probably very common LOL.

This might be a good argument for adding associated pass rule creation as a feature when creating a tunnel, similar to what is done for port forwarding

tquade

@theonemcdonald I ran into a similar issue and stronly support your thoughts. In my view a good model to follow is that set out for IPSec and openVPN particularly with regard to outbound NAT rules when setting up a server.

Ted Quade

brians

@theonemcdonald

But is it possible to even make a rule before the interface is assigned? Don't you still have to go and select/assign it after making the tunnel?

brians

What is the purpose of Interface addresses?
When I assign to an interface I assign the IP address to the interface and the values entered here previously disappear and are not used. If I un-assign they re-appear.

cmcdonald

@brians said in WireGuard lives!:

What is the purpose of Interface addresses?
When I assign to an interface I assign the IP address to the interface and the values entered here previously disappear and are not used. If I un-assign they re-appear.

This is for configuring WireGuard tunnels that are not assigned to a pfSense interface. Yea that is a bit confusing. But basically you can have two different types of WireGuard tunnels, which sort of depend on what you intend to do with them. It is possible to build WireGuard tunnels that aren't associated with a specific pfSense interface. These WireGuard tunnels are filtered using the "WireGuard" interface group. The addresses for unassigned tunnels are configured through the WireGuard UI. However, once you assign a WireGuard tunnel to a pfSense interface, pfSense takes over the address assignment, so the WireGaurd UI changes to reflect that...and instead you're left with a link to the native pfSense UI for configuring addresses:

We do this because we don't want to step on pfSense's toes when it comes to things that it should be handling.

brians

@theonemcdonald ok thanks, can you give me an example of your first tunnel named Remote Access?

I have my iPhone setup with an actual interface, is there a way to make it simpler without assigning an interface like this?

cmcdonald

@brians

brians

@theonemcdonald
Thanks, I though I would try myself and got working and then came back to update but you already responded :)

I didn't realize could do without an interface so this is much nicer...

cmcdonald

@brians oh no worries! Glad it is working!

Assigning as an interface is useful if you intend to route traffic over the WireGuard tunnel. For instance, you'll notice in my example Remote Access is unassigned but my Mullvad tunnel is assigned (because I need to be able to do policy routing over the mullvad tunnel).

Generally speaking, if you're doing Road Warrior, you don't need to assign the interface...but if you're doing Site-to-Site, you'll probably need to assign it.

brians

Tried latest v0.1.2_3 with no issues.

Also noticed that on my work SG-5100 the Gui package manager has 0.1.1 now.

I see v0.1.2_3 is a release candidate so probable will see that version soon for general availability.

cmcdonald

@brians Yep, working hard on this! Soon

JeGr

@theonemcdonald said in WireGuard lives!:

@brians Yep, working hard on this! Soon

Is it currently planned to inlcude the wireguard package in the list for 2.5.2-release or only for 2.6(-dev)? At least having it with a -dev/-experimental or /-beta/-alpha label in 2.5.2 would be nice, but currently 2.5.2-betas don't have it listed. I think it would really help bringing additional helpers and eyes to your package and we can help work out the kinks :)

Cheers
\jens

martywd

I've been using wireguard on '2.5.1-RELEASE (amd64)' since v0.0.8 was released, upgrading every time a new release was added. Updated yesterday from v0.1.2_6 to v0.1.3. This where I stand at the moment:

pfSense-pkg-WireGuard 0.1.3
wireguard-kmod 0.0.20210606
wireguard-tools-lite 1.0.20210424

One issue I've noticed since doing yesterday's update is shown as follows (Public key removed from the image, all else is as appears, sans the red eclipse ... of course!). This is from 2.5.1's menu: 'Status|Wireguard|Tunnels' and clicking on 'Show Peers' button. Possibly this is because I'm using 2.5.1? idk?

This seems cosmetic since my wireguard connect in pfsense continues to work without issues.

In the 'Status' window the 'Peers' show as expected (again, keys and endpoint:ports removed by me from this image).

v0.1.3_status.png

.

vjizzle

Hi! I am running wireguard on 2.5.2 rc. I have no tunnels configured because this system is running in a virtual machine on my homelab.

After upgrading to the latest version of wireguard I still see these errors:

Crash report begins. Anonymous machine information:

amd64
12.2-STABLE
FreeBSD 12.2-STABLE RELENG_2_5_2-n226661-b1c18988dca pfSense

Crash report details:

PHP Errors:
[24-Jun-2021 11:28:59 Europe/Amsterdam] PHP Warning: flock() expects parameter 1 to be resource, null given in /usr/local/pkg/wireguard/wg_service.inc on line 324
[24-Jun-2021 11:28:59 Europe/Amsterdam] PHP Warning: fclose() expects parameter 1 to be resource, null given in /usr/local/pkg/wireguard/wg_service.inc on line 327
[24-Jun-2021 11:29:19 Europe/Amsterdam] PHP Warning: flock() expects parameter 1 to be resource, null given in /usr/local/pkg/wireguard/wg_service.inc on line 324
[24-Jun-2021 11:29:19 Europe/Amsterdam] PHP Warning: fclose() expects parameter 1 to be resource, null given in /usr/local/pkg/wireguard/wg_service.inc on line 327

No FreeBSD crash data found.

I hope this is all cosmetic but please let me know if I can help troubleshoot this.

cmcdonald

@vjizzle Fix for this is included in the latest release which was accepted yesterday. It should be available very soon

dersch

@theonemcdonald i'm missing the routing overview inside the status view wt 0.1.3

dersch

And what is about to add routes to allowed networks automatically?

cmcdonald

@dersch That was backed out until a more suitable overall solution for routes is built. Right now, you will need to either a) use a dynamic routing protocol or b) create static routes to direct traffic out a certain WG tunnel interface. This is being worked on

emikaadeo

@theonemcdonald Is your repo still working? Got some issues with checking updates https://forum.netgate.com/post/989073

cmcdonald

@emikaadeo the guys who maintain that are working on it. But the repo is indeed down atm. My recommendation would be to uninstall that custom repo and either a) side-load or b) get the code from Netgate's repo. Now that things are settling down a bit with the code and design, expect more frequent updates from the official Netgate repository.