Page MenuHomeFreeBSD

net/amneziawg-kmod and net/amneziawg-tools: ports for fast, modern and secure AmneziaWG VPN with anti-detection tweaks
ClosedPublic

Authored by vova_fbsd.ru on Jul 11 2025, 5:48 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Aug 31, 10:15 AM
Unknown Object (File)
Mon, Aug 25, 2:15 PM
Unknown Object (File)
Thu, Aug 21, 4:30 PM
Unknown Object (File)
Wed, Aug 20, 3:06 PM
Unknown Object (File)
Wed, Aug 20, 2:18 PM
Unknown Object (File)
Wed, Aug 20, 4:31 AM
Unknown Object (File)
Wed, Aug 13, 11:34 PM
Unknown Object (File)
Wed, Aug 13, 12:59 AM
Tokens
"Like" token, awarded by osa.

Details

Summary

AmneziaWG is a simple, fast, and secure VPN that utilizes state-of-the-art
cryptography. This version adds DPI-bypassing tweaks.

https://github.com/vgrebenschikov/amneziawg-tools

Test Plan

To test if_awg.ko:

if=$(ifconfig awg create inet 192.168.1.1/24 up)
ifconfig $if
  awg0: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
	options=80000<LINKSTATE>
	inet 192.168.1.1 netmask 0xffffff00
	groups: awg
	nd6 options=109<PERFORMNUD,IFDISABLED,NO_DAD>

awg set $if jc 7 jmin 150 jmax 1000 s1 117 s2 321 h1 2008066467 h2 2351746464 h3 3053333659 h4 1789444460
awg set $if listen-port 12345 private-key <(awg genkey) peer $(awg genkey | awg pubkey) allowed-ips 192.168.1.2/32

awg show $if
  interface: awg0
    public key: yyAHM...
    private key: (hidden)
    listening port: 12345
    jc: 7
    jmin: 150
    jmax: 1000
    s1: 117
    s2: 321
    h1: 2008066467
    h2: 2351746464
    h3: 3053333659
    h4: 1789444460

peer: bdfTF..
  allowed ips: 192.168.1.2/32

to test with awg-quck tool:

# cd /usr/local/etc/amnezia/amneziawg/
# cat > awg0.conf << EOF
[Interface]
PrivateKey = $(awg genkey)
ListenPort = 12345
Address = 192.168.1.1/24
Description = Test AmneziaWG

Jc = 7
Jmin = 150
Jmax = 1000
S1 = 117
S2 = 321
H1 = 2008066467
H2 = 2351746464
H3 = 3053333659
H4 = 1789444460

[Peer]
PublicKey = $(awg genkey | awg pubkey)
AllowedIPs = 192.168.1.2/32
EOF

awg-quick up awg0
[#] ifconfig awg create name awg0 description Test AmneziaWG
[#] awg setconf awg0 /dev/stdin
[#] ifconfig awg0 inet 192.168.1.1/24 alias
[#] ifconfig awg0 mtu 1420
[#] ifconfig awg0 up
[#] route -q -n add -inet 192.168.1.2/32 -interface awg0
[+] Backgrounding route monitor

awg show
interface: awg0
  public key: CI...
  private key: (hidden)
  listening port: 12345
  jc: 7
  jmin: 150
  jmax: 1000
  s1: 117
  s2: 321
  h1: 2008066467
  h2: 2351746464
  h3: 3053333659
  h4: 1789444460

peer: kue...
  allowed ips: 192.168.1.2/32

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 65670
Build 62553: arc lint + arc unit

Event Timeline

vova_fbsd.ru created this revision.
  • bump wireguard-amnezia-kmod-v1.0.4

I'm uncomfortable with you calling this "wireguard" in any way shape or form.

I'm uncomfortable with you calling this "wireguard" in any way shape or form.

Can you explain please your position please?
It is fully compatible with wireguard protocol:

    • any normal wg client can interoperate through this driver from one side,
  • and this driver can be used as replacement for normal if_wg

Also, will "net/amneziawg-kmod" and "if_awg" - fit for you?

Any attempts of upstreaming?

Any attempts of upstreaming?

yes, theres was attempt to add it to base - see https://reviews.freebsd.org/D51239#1170295
according it - WireGuard project was declined to accept the whole idea of such extension, so guys are against including into FreeBSD's implementation of wireguard as well.

I've asked there if it worth to expose netgraph hooks from wg driver to have plugin system on top of netgraph... but no answer yet.

net/amneziawg-kmod and net/amneziawg-tools

  • use upstream-matching names fo rboth ports: kmod and tools
  • use unique interface name for kmod - if_awg, similar to upstream
vova_fbsd.ru retitled this revision from net/wireguard-amnezia-kmod: WireGuard implementation with Amnezia support to net/amneziawg-kmod and net/amneziawg-tools: ports for fast, modern and secure AmneziaWG VPN with anti-detection tweaks.Jul 22 2025, 11:06 PM
vova_fbsd.ru edited the summary of this revision. (Show Details)
vova_fbsd.ru edited the test plan for this revision. (Show Details)

I think calling it something with "wg" in the name also is like cheating on your homework, poorly. "My dog ate my homework" level of silliness. Like... we all see it there. So just don't do it. Quit trying to call it WireGuard. Make your own VPN protocol, do all sorts of fun things, add this or that random obfuscation idea, whatever. Networking is fun; I don't want to stop you from enjoying yourself. I'm just asking that you don't try to peddle this as some kind of WireGuard thing, because from my perspective, it really is not. And I think this perspective suits us both: by getting rid of "wg" and not trying to pretend it's WireGuard, you get me totally out of your hair and you get to do whatever you want and I don't need to worry about it. And _then_ if you do come across some good ideas you want to upstream or talk to upstream about including in a protocol or whatever else, you can happily send an email to the mailing list, "hey I made a different non-wireguard thing, but I think this would be a cool idea to add. What do you guys think?" And then we can look at it and see. But, anyway, all of that begins by you not trying to pretend this is "wg" anything.

Sad to hear that ...

I think calling it something with "wg" in the name also is like cheating on your homework, poorly.

Following your logic, FreeBSD should never be named like that, as BSD letters were already taken by BSDi. I thought that is one of the key features of open source - you can derive new projects based on existing, keeping backward compatibility and empowering both.

So just don't do it. Quit trying to call it WireGuard. Make your own VPN protocol, do all sorts of fun things, add this or that random obfuscation idea, whatever.

I had no idea to invent a new protocol. I just ported an existing project.
Anyway, I didn’t mean to argue about naming - the original project is called AmneziaWG, and I’m not the one who named it.
I merely ported it (this review is only about the porting effort).

And _then_ if you do come across some good ideas you want to upstream or talk to upstream about including in a protocol or whatever else, you can happily send an email to the mailing list, "hey I made a different non-wireguard thing, but I think this would be a cool idea to add. What do you guys think?"

I did try to contribute something upstream - at least that’s how I saw it.
I submitted a patch as #D51239, which you rejected — that’s fine, I accepted it.
Maybe, as you said, I should’ve written to the mailing list first (or joined the IRC discussion).
Honestly, I don’t feel like spending much time arguing about it - and to be honest, the overall tone of the discussion feels somewhat discouraging.

I assumed that the WireGuard implementation in FreeBSD (in sys/dev/wg) is “upstream”, but I guess I was mistaken.
From what I’ve seen, there’s not much overlap between the Linux kernel driver and the FreeBSD one.

Networking is fun;

It’s not fun at all if you’re expected to implement an entire networking stack from scratch just to experiment with something. And to me, that’s what your suggestion sounded like.

I don't want to stop you from enjoying yourself.

Do you think it’s a bad idea to extend the existing WireGuard driver with Netgraph hooks for custom UDP stream processing?
(Similar to how mpd handles PPP streams in flexible ways.) — just a side question.
Would that be a question better suited for the mailing list?

Do you think it’s a bad idea to extend the existing WireGuard driver with Netgraph hooks or custom UDP stream processing? (Similar to how mpd handles PPP streams in flexible ways.) — just a side question. Would that be a question better suited for the mailing list?

That sounds pretty intriguing to me. I'd be interested to learn how this would work on Linux too, and maybe even user space implementations, and what a generic library api for accessing this would be like. What sorts of events would bubble up? And would this be better suited as an in-kernel eBPF hook? I am definitely interested in kernel hooks for efficiently plugging in different obfuscators or encapsulators. If you've got a big idea about this, indeed the mailing list would probably be a good venue, especially if you CC in Kyle & folks from here whose feedback are really valuable.

Do you think it’s a bad idea to extend the existing WireGuard driver with Netgraph hooks or custom UDP stream processing? (Similar to how mpd handles PPP streams in flexible ways.) — just a side question. Would that be a question better suited for the mailing list?

That sounds pretty intriguing to me. I'd be interested to learn how this would work on Linux too, and maybe even user space implementations, and what a generic library api for accessing this would be like. What sorts of events would bubble up? And would this be better suited as an in-kernel eBPF hook? I am definitely interested in kernel hooks for efficiently plugging in different obfuscators or encapsulators. If you've got a big idea about this, indeed the mailing list would probably be a good venue, especially if you CC in Kyle & folks from here whose feedback are really valuable.

Can you suggest which mailing list would be most appropriate? (WireGuard-specific or freebsd-net@?)

As for the idea — frankly, I wouldn’t call it “big”, but essentially:

The ng_ksocket interface seems quite suitable. So, whenever a new socket is needed in if_wg.c, instead of allocating it directly in the driver, a new Netgraph node of a given type (by default ng_ksocket) could be spawned.
This node would handle bind/setsockopt/send/receive instead of implementing those directly in if_wg.c. (It would probably also require handling FIB and jail context propagation.)

And if someone wants to implement additional functionality, it should be sufficient to provide an alternative node in place of ng_ksocket.

But this is just an idea — I haven’t studied it in depth.

vova_fbsd.ru edited the test plan for this revision. (Show Details)
  • remove not used any more rc.d file

v1.0.6 of upstream driver, only cosmetic changes

use awg0/awg1 in rc.conf example

This revision was not accepted when it landed; it landed in state Needs Review.Jul 26 2025, 2:21 PM
This revision was automatically updated to reflect the committed changes.

@eugen_grosbein.net why would you land this when it was still being contested?

Why would you merge this?

No merges to FreeBSD base system were done nor intended.
Only ports for external https://amnezia.org/ project got to the FreeBSD Ports Collection on direct request of submitter to me.

Weird. Sounds like it should be reverted.

Weird. Sounds like it should be reverted.

I've now backed them out[1] and described how they can move forward with their software in ports[2].

[1] https://cgit.freebsd.org/ports/commit/?id=106b0f0538b846821a27c20a554c453d6799aec9
[2] https://lists.freebsd.org/archives/dev-commits-ports-main/2025-July/157817.html

Obviously nothing stops them from using if_wg as the basis and that's
all fine, but the upstream WireGuard project has already expressed their
concern and have been completely ignored. Just re-brand the damn thing
as Amnezia and an Amnezia tunnel, fix the docs to avoid calling it
WireGuard. We'll get it into review and commit it, then then let's
perhaps chat on the list (as already requested) about how we could
integrate other ideas that can improve WireGuard as a whole.

@kevans , just to be absolutely clear -

we are discussing here FreeBSD port of 3rd party software - AmeneziaWG ( https://docs.amnezia.org/documentation/amnezia-wg/ )

I've did following according to request of Jason:

  1. renamed "wireguard-amnezia-kmod" to "amneziawg-kmod" (exactly as 3rd party project named)
  2. renamed interface if_wg -> if_awg (interface name and interface group), exactly the same name as was used by 3rd party and not matching if_wg

Synchronized pkg-descr with description from site above.

What I did wrong and why you have reverted these ports?

Obviously nothing stops them from using if_wg as the basis and that's
all fine, but the upstream WireGuard project has already expressed their
concern and have been completely ignored. Just re-brand the damn thing
as Amnezia and an Amnezia tunnel, fix the docs to avoid calling it
WireGuard. We'll get it into review and commit it, then then let's
perhaps chat on the list (as already requested) about how we could
integrate other ideas that can improve WireGuard as a whole.

@kevans , just to be absolutely clear -

we are discussing here FreeBSD port of 3rd party software - AmeneziaWG ( https://docs.amnezia.org/documentation/amnezia-wg/ )

Yes, I am aware.

I've did following according to request of Jason:

  1. renamed "wireguard-amnezia-kmod" to "amneziawg-kmod" (exactly as 3rd party project named)
  2. renamed interface if_wg -> if_awg (interface name and interface group), exactly the same name as was used by 3rd party and not matching if_wg

Synchronized pkg-descr with description from site above.

What I did wrong and why you have reverted these ports?

Drop the 'wg' from the name and any description/advertising materials. That's just another spelling for 'WireGuard'.

Bypassing our usual procedure isn't cool, and Eugen shouldn't have done the same. This is in review and has committers tagged that have been engaged, doing an end-run around while discussions are taking place is not how we should be doing things.

we are discussing here FreeBSD port of 3rd party software - AmeneziaWG ( https://docs.amnezia.org/documentation/amnezia-wg/ )

Yes, I am aware.

What I did wrong and why you have reverted these ports?

Drop the 'wg' from the name and any description/advertising materials. That's just another spelling for 'WireGuard'.

I don't think I can agree with that, sounds quite doubtful to me and reminds situation with OpenSSH vs. SSH.

The Amnezia VPN project is available for a long enough time. Is there were any complains from the original project has been raised?

Drop the 'wg' from the name and any description/advertising materials. That's just another spelling for 'WireGuard'.

Can you explain motivation for that?

my motivation why it should be named as "amneziawg" and if_awg

  1. port name exactly matches upstream project (amneziawg)
  2. interface name exactly matches interface names of upstream project for various platforms
  3. the name did not conflict with any of exising interfaces
  4. overall practice to give short (few letters) names to interfaces provided not much chances to not have sub-string intersections
  5. the port provides protocol-level compatibility with wireguard protocol with proper configuration
  6. "awg" or "amneziawg" names are not covered with trademarks or similar

Bypassing our usual procedure isn't cool, and Eugen shouldn't have done the same.
This is in review and has committers tagged that have been engaged, doing an end-run around while discussions are taking place is not how we should be doing things.

That was not obvious et all for me that discussion was "in progress", I am sorry for that,
how I seen the discussion:
you have invided Jason (into base tree review), who was provided comments strongly against - 1. merging this into base (or upstream), 2. "quit trying to call it wireguard"
I've fixed both - the first as giving up on idea to merge into base, the second by renaming to amneziawg/if_awg

then discussion was a little bit around netgraph hooks and moving to mailing lists to discuss that.
I seen no more intention to comment on renamed patches or follow up, then I was asked someone else to proceed.

In D51265#1177616, @osa wrote:

we are discussing here FreeBSD port of 3rd party software - AmeneziaWG ( https://docs.amnezia.org/documentation/amnezia-wg/ )

Yes, I am aware.

What I did wrong and why you have reverted these ports?

Drop the 'wg' from the name and any description/advertising materials. That's just another spelling for 'WireGuard'.

I don't think I can agree with that, sounds quite doubtful to me and reminds situation with OpenSSH vs. SSH.

The Amnezia VPN project is available for a long enough time. Is there were any complains from the original project has been raised?

No idea, most people in these reviews have only heard of Amnezia as of late, AFAIK, and were thus only recently made aware that they're branding themselves as such. Amnezia is (apparently) a commerical project, WireGuard is a registered trademark, and we don't really like to make a habit of irritating people that hold registered trademarks.

Drop the 'wg' from the name and any description/advertising materials. That's just another spelling for 'WireGuard'.

Can you explain motivation for that?

my motivation why it should be named as "amneziawg" and if_awg

  1. port name exactly matches upstream project (amneziawg)
  2. interface name exactly matches interface names of upstream project for various platforms
  3. the name did not conflict with any of exising interfaces
  4. overall practice to give short (few letters) names to interfaces provided not much chances to not have sub-string intersections
  5. the port provides protocol-level compatibility with wireguard protocol with proper configuration
  6. "awg" or "amneziawg" names are not covered with trademarks or similar

Bypassing our usual procedure isn't cool, and Eugen shouldn't have done the same.
This is in review and has committers tagged that have been engaged, doing an end-run around while discussions are taking place is not how we should be doing things.

That was not obvious et all for me that discussion was "in progress", I am sorry for that,
how I seen the discussion:
you have invided Jason (into base tree review), who was provided comments strongly against - 1. merging this into base (or upstream), 2. "quit trying to call it wireguard"
I've fixed both - the first as giving up on idea to merge into base, the second by renaming to amneziawg/if_awg

then discussion was a little bit around netgraph hooks and moving to mailing lists to discuss that.
I seen no more intention to comment on renamed patches or follow up, then I was asked someone else to proceed.

The correct action there was to drop a comment in this review: "Hey, is there any way we can move forward with this port in the meantime?"

(for what it's worth, "amneziavpn-" would seem like a fine name that ties back into the website better anyways)

Drop the 'wg' from the name and any description/advertising materials. That's just another spelling for 'WireGuard'.

I don't think I can agree with that, sounds quite doubtful to me and reminds situation with OpenSSH vs. SSH.
The Amnezia VPN project is available for a long enough time. Is there were any complains from the original project has been raised?

No idea, most people in these reviews have only heard of Amnezia as of late, AFAIK, and were thus only recently made aware that they're branding themselves as such.
Amnezia is (apparently) a commerical project,

I don't think so. The original site is unavailable at the moment, so here's the the brief description of the project from the Wikipedia

Amnezia VPN is a free and open-source application that allows users to create a personal VPN using their own server. It uses the OpenVPN, WireGuard, Shadowsocks, IKEv2 and Cloak protocols.

WireGuard is a registered trademark, and we don't really like to make a habit of irritating people that hold registered trademarks.

Well, that's why it's been renamed by the requestor to more convenient name - if_awg, that's clear to me. Not a professional layer, but I don't think I see any violations here.
Again, I want to remind sort of similar situation with SSH vs OpenSSH, https://it.slashdot.org/story/01/02/16/0217209/the-ssh-vs-openssh-trademark-battle-next-round

(for what it's worth, "amneziavpn-" would seem like a fine name that ties back into the website better anyways)

Amnezia-VPN project provides support for multiple VPN protocols, and only one of them is amneziawg, the port support only that protocol, and does not support others.
In case of "amneziavpn" - such name will misslead users.

You can check, for example how they name relative repos in their github -
about amneziawg:

https://github.com/amnezia-vpn/amneziawg-tools
https://github.com/amnezia-vpn/amneziawg-linux-kernel-module

Can you please answer on my question about motivation to not name it "amneziawg"?

(for what it's worth, "amneziavpn-" would seem like a fine name that ties back into the website better anyways)

Amnezia-VPN project provides support for multiple VPN protocols, and only one of them is amneziawg, the port support only that protocol, and does not support others.
In case of "amneziavpn" - such name will misslead users.

You can check, for example how they name relative repos in their github -
about amneziawg:

https://github.com/amnezia-vpn/amneziawg-tools
https://github.com/amnezia-vpn/amneziawg-linux-kernel-module

Can you please answer on my question about motivation to not name it "amneziawg"?

Because you were asked not to, and that's clearly a pretty thin line to be dancing around..

(for what it's worth, "amneziavpn-" would seem like a fine name that ties back into the website better anyways)

Amnezia-VPN project provides support for multiple VPN protocols, and only one of them is amneziawg, the port support only that protocol, and does not support others.
In case of "amneziavpn" - such name will misslead users.

You can check, for example how they name relative repos in their github -
about amneziawg:

https://github.com/amnezia-vpn/amneziawg-tools
https://github.com/amnezia-vpn/amneziawg-linux-kernel-module

Can you please answer on my question about motivation to not name it "amneziawg"?

Because you were asked not to, and that's clearly a pretty thin line to be dancing around..

(for what it's worth, "amneziavpn-" would seem like a fine name that ties back into the website better anyways)

Amnezia-VPN project provides support for multiple VPN protocols, and only one of them is amneziawg, the port support only that protocol, and does not support others.
In case of "amneziavpn" - such name will misslead users.

You can check, for example how they name relative repos in their github -
about amneziawg:

https://github.com/amnezia-vpn/amneziawg-tools
https://github.com/amnezia-vpn/amneziawg-linux-kernel-module

Can you please answer on my question about motivation to not name it "amneziawg"?

Because you were asked not to, and that's clearly a pretty thin line to be dancing around..

hm ...

From Jason’s message, it’s quite clear that he’s opposed to using the name WireGuard or presenting the project as being WireGuard-compatible. However, it is less clear whether there’s a strong objection specifically to the use of “wg” as part of the name, especially in a clearly distinct name like amneziawg, which does not claim to be WireGuard itself.

It would be helpful to have this distinction clarified. My intention is not to mislead or infringe on anything, but rather to keep the naming consistent with the upstream project and existing interface names, while avoiding conflicts with other names.

I’d really appreciate continuing this discussion on the basis of clear motivations and technical or legal concerns, rather than personal preferences alone. That would make it easier for all sides to understand each other and work towards something mutually acceptable.

(for what it's worth, "amneziavpn-" would seem like a fine name that ties back into the website better anyways)

Amnezia-VPN project provides support for multiple VPN protocols, and only one of them is amneziawg, the port support only that protocol, and does not support others.
In case of "amneziavpn" - such name will misslead users.

You can check, for example how they name relative repos in their github -
about amneziawg:

https://github.com/amnezia-vpn/amneziawg-tools
https://github.com/amnezia-vpn/amneziawg-linux-kernel-module

Can you please answer on my question about motivation to not name it "amneziawg"?

Because you were asked not to, and that's clearly a pretty thin line to be dancing around..

(for what it's worth, "amneziavpn-" would seem like a fine name that ties back into the website better anyways)

Amnezia-VPN project provides support for multiple VPN protocols, and only one of them is amneziawg, the port support only that protocol, and does not support others.
In case of "amneziavpn" - such name will misslead users.

You can check, for example how they name relative repos in their github -
about amneziawg:

https://github.com/amnezia-vpn/amneziawg-tools
https://github.com/amnezia-vpn/amneziawg-linux-kernel-module

Can you please answer on my question about motivation to not name it "amneziawg"?

Because you were asked not to, and that's clearly a pretty thin line to be dancing around..

hm ...

From Jason’s message, it’s quite clear that he’s opposed to using the name WireGuard or presenting the project as being WireGuard-compatible. However, it is less clear whether there’s a strong objection specifically to the use of “wg” as part of the name, especially in a clearly distinct name like amneziawg, which does not claim to be WireGuard itself.

You directly responded to a message in which he was objecting to 'wg' -- it's a bit further up, but in this review still.

It would be helpful to have this distinction clarified. My intention is not to mislead or infringe on anything, but rather to keep the naming consistent with the upstream project and existing interface names, while avoiding conflicts with other names.

I’d really appreciate continuing this discussion on the basis of clear motivations and technical or legal concerns, rather than personal preferences alone. That would make it easier for all sides to understand each other and work towards something mutually acceptable.

I'm going to have to leave you to have that conversation with others, sorry. My day started out rather annoyed that this was committed by a third-party that clearly hadn't tried to understand the context, and it's only driven my blood pressure higher since. I appreciate that you're trying to work toward something more acceptable, but I need to step away for my own physical/mental health, here, and I'm not sure that I can be objective anymore.

The interface name awg is already taken, https://cgit.freebsd.org/src/tree/sys/arm/allwinner/if_awg.c?h=releng/14.3

Out of curiosity, is there a reason why this needs to be in ports to begin with?
What prevents users from doing pkg add <URL> using a prebuilt package from the service provider or adding a secondary repo which seems to be a pretty common practice for VPN providers?

Good point, Daniel. So, Amnesia VPN interface can be renamed to avoid such conflicts.

Out of curiosity, is there a reason why this needs to be in ports to begin with?
What prevents users from doing pkg add <URL> using a prebuilt package from the service provider or adding a secondary repo which seems to be a pretty common practice for VPN providers?

This is great idea. GitHub and Cirrus CI supports multiple version of FreeBSD, so it's definitely doable.

Out of curiosity, is there a reason why this needs to be in ports to begin with?
What prevents users from doing pkg add <URL> using a prebuilt package from the service provider or adding a secondary repo which seems to be a pretty common practice for VPN providers?

Exactly the same reason why all other ports reside in port collection - a unified way to explore/find the port/maintain the ports - with CI/CD and hosting infrastructure.
I am pretty happy to use my public repo for building these ports, even more, I am abosolutely happy to build the port even in original state w/o renaming.
But for other users it absolutely unobvious how to find the port or if it worth to trust the port site and so on.

The whole effort of submitting it to ports tree was because of user's demand, not because I have nothing to do.
Maintaining CI/CD and hosting infrastructure for a private ports collection is not something I’m interested in doing.

by the way, I had already a questions about "if the port compatible with pfSense".

As this review was closed, I've submitted the fixed version as 288599

What was changed:

  • ports are renamed to amnezia-kmod and amnezia-tools
  • port description adjusted to just mention compatibility with WireGuard protocol
  • netif name was changed if_awg -> if_amn