This PR should resolve RM ticket 11588.

It adds a new setting option Suggest Next Approved IP.

If the above setting is enabled, when a user creates a new peer (for an existing tunnel atm, need to look at breaking out to JS so we can pick it up when the user navigates to Add New Peer page without pre-selecting a tunnel) it will work out what the next available IP address is.

It does this by working out the subnet value, broadcast value, and any existing peers. Once we have these values we can iterate from the subnet + 1 up until broadcast - 1, the first available IP address is "taken".

So we have the following examples of expected behaviour:

• Tunnel's assigned interface has static IPv4 address of 192.168.100.1 with cidr range of /24

  • Peers with the IP addresses: 192.168.100.2, 192.168.100.3, 192.168.100.4, 192.168.100.6, 192.168.100.7
  • With the above setting enabled, when click the "Add new peer for this tunnel" button, it will pre-fill the ApprovedIP list with the address 192.168.100.5/32 given it's available. Doing this a second time (if we create .100.5) will result in the IP address 192.168.100.8/32 being suggested

• Tunnel's WG specified IP address of 192.168.150.254/24

  • Suggests IP address 192.168.150.1/32

In this PR I'm iterating from subnet to broadcast as we can't assume the interface address is always lowest (.1/24 for example) as it could also be highest (.254/24 for example).

This is currently a work in progress and should not be deployed.

This PR allows the user to configure the default visibility for all Peers on the Status page.

Personally I like to see all Peers on status page load as I don't have too many. It defaults to true (consistent with pre PR behaviour).

There are still a few TODO comments and QR config options left unfilled (DNS, MTU, Endpoint) which are discussed here.

Need to look at how to reference / link back the JS library used this one which has an MIT licence.

Hopefully this implements #7 better than my initial attempt

This makes the widget more repsponsive and displays changes in active peers, transferred bytes, and even state changes of the WireGuard service.

This is a basic update which just updatesa the entire DOMs HTML as other widgets seem to do.

Adds to #119

After downing & upping WG site to site tunnels, or stopping / restarting the service, any static routes are lost and the tunnels break if you're not using FRR/BGP etc.

This adds a call to system_staticroutes_configure() in wg_service.inc so the routes get re-added. I tested this on 22.05.b.20220512.0600 with 2 S2S tunnels and a RemoteAccess tunnel.

see https://redmine.pfsense.org/issues/13153

Resolves RM ticket 11465.

This PR will add validation checks and user feedback if they attempt to add a new peer to a tunnel which already has another peer with either 0.0.0.0/0 or ::/0 (or both) default routes specified in the allowed ips list, which is not valid.

Current plugin validation does not catch this issue.

I do have a query regarding a difference between this plugin and the original WG implementation; the ticket lists a bunch of test scenarios:

PASS    Create a tunnel with one peer that has Allowed IPs empty -- should succeed

PASS    Create a tunnel with the first peer Allowed IPs set to "10.0.0.0/24" or equivalent non-default network
PASS    Add a peer to this tunnel with Allowed IPs set to "0.0.0.0/0" -- should succeed (first IPv4 default for this tunnel)
PASS    Add a peer to this tunnel with Allowed IPs set to "::/0" -- should succeed (first IPv6 default for this tunnel)
FAIL    Add a peer to this tunnel with Allowed IPs empty -- should fail (additional attempt at IPv4 and IPv6 default)
PASS    Add a peer to this tunnel with Allowed IPs set to "0.0.0.0/0" -- should fail
PASS    Add a peer to this tunnel with Allowed IPs set to "::/0" -- should fail

    Create a tunnel with the first peer Allowed IPs set to "10.0.0.0/24" or equivalent non-default network -- should succeed
    Add a peer to this tunnel with Allowed IPs empty -- should succeed (IPv4 and IPv6 default for this tunnel)
    Add a peer to this tunnel with Allowed IPs empty -- should fail
    Add a peer to this tunnel with Allowed IPs set to "::/0" -- should fail
    Add a peer to this tunnel with Allowed IPs set to "0.0.0.0/0" -- should fail

    Create a tunnel with the first peer Allowed IPs empty -- should succeed
    Add a peer to this tunnel with Allowed IPs set to "::/0" -- should fail
    Add a peer to this tunnel with Allowed IPs set to "0.0.0.0/0" -- should fail
    Add a peer to this tunnel with Allowed IPs set to "10.0.1.0/24" -- should succeed
    Add a peer to this tunnel with Allowed IPs set to "fc07:1::0/64" -- should succeed

    Create a tunnel with the first peer Allowed IPs set to "10.5.0.0/24" or equivalent non-default network -- should succeed
    Add a peer to this tunnel with Allowed IPs set to "10.5.1.0/24" -- should succeed
    Add a peer to this tunnel with Allowed IPs set to "10.5.2.0/24" -- should succeed

However does this plugin actually take an allowed IPs list of (none) to equate the default route for both IPv4 and IPv6 for this tunnel? I've a hunch it doesn't and because it doesn't the provided validation logic will not catch this scenario.

It will prevent any attempt to add a new peer to a tunnel which already has a default route (checks 0.0.0.0/0 or v4 and ::/0 for v6); which leads onto my section question, which is more generic.

Does this wireguard plugin (or anything in pSense more generally) validate IPv6 ::/0 addresses for compression? As currently a user could "bypass" this new IPv6 default route validation by providing any of the following values instead:

• 0::/0
• 0:0000:0::/0
• ::0/0
• etc

But would WG / any other pfSense component actually accept these variants of the same address for routing purposes?

Resolves redmine ticket: 12258

Added more JS logic to allow for browsers who wont allow access to navigator.clipboard API to still copy public keys for tunnels, peers list and tunnel edit.

Works on HTTP admin access as a fallback, still attempts the modern API first

Inline with my previous PR of using CSS to display:none the items we didn't want to see on page load (tunnels list always and status page only if use has unchecked hide peers checkbox).

I still feel leacing it to the JS to hide the rows leads to poor UX with flickering

This commit brings along a very simple widget for the dashboard page which displays all tunnels configured, their description, # of peers, listening port, and traffic stats.

Will display info boxes if:

• The service is not running
• No tunnels are configured

This widget is a copy-pasta from the wg status code, but slimmed down to not show peers and all the tunnel details.

Discussions should be had around what fields people care about as it could easily be too "busy" for a widget.

Also this can be a starting point for adding actions into the widget such as restarting tunnels, toggling peers, etc

Implements #119

This PR resolves redmine issue 12251.

It does so in two parts:

• Validate the user provided keepalive to check for 16 bit uint value (0-65535)
• Allow the WG Config class to write out the default value of "0" to a config

Now a user will be informed and a bad value rejected if not within 0-65535, and the default value of 0 is now actually written out to the configs.

Tunnel list page featuring the tunnel's public key in a table and the Peers list page featuring the peer's public key both have JS events alowing the user to click on them to copy their value, however I only kno about this due to looking at the source code and console errors (previous PR fixed); Having the cursor set to pointer will at least show the user it's clickable, and hopefully they find out it copies the value. Being able to provide a toast or similar may be more useful for UX feedback.

When loading tunnels page or status page, the DOM will flicker as divs are loaded with a display but JS then hides them when loaded.

This PR:

• Resolves flickering on tunnel list page, and settings page
• Ensures cursor: pointer is set on the Tunnel list page and the peers lis page for the Tunne / Peer public key field which is truncated