AmneziaWG is a simple, fast, and secure VPN that utilizes state-of-the-art
cryptography. This version adds DPI-bypassing tweaks.
Details
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
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?
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
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 ...
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.
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.
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.
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:
- renamed "wireguard-amnezia-kmod" to "amneziawg-kmod" (exactly as 3rd party project named)
- 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?
Yes, I am aware.
I've did following according to request of Jason:
- renamed "wireguard-amnezia-kmod" to "amneziawg-kmod" (exactly as 3rd party project named)
- 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?
Can you explain motivation for that?
my motivation why it should be named as "amneziawg" and if_awg
- port name exactly matches upstream project (amneziawg)
- interface name exactly matches interface names of upstream project for various platforms
- the name did not conflict with any of exising interfaces
- overall practice to give short (few letters) names to interfaces provided not much chances to not have sub-string intersections
- the port provides protocol-level compatibility with wireguard protocol with proper configuration
- "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.
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.
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
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.
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