# lucktu/n2n: prebuilt n2n binaries and a version map of three forks > This repository collects compiled edge and supernode binaries for n2n, the peer-to-peer VPN, so that people who cannot compile can still run it. It also keeps a dated changelog across three separate n2n code lines, which is the most useful thing in the file, because the versioning conventions differ between them. **lucktu/n2n** — Provide the binaries(edges and supernodes) of n2n that I collected - Repository: https://github.com/lucktu/n2n - Stars: 616 · Forks: 155 - Language: Unknown - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/lucktu-n2n ## A binary mirror, not a fork, with the reasoning stated up front The purpose of the repository is narrow and the README is honest about the reason. Compiling is also a technical job, and many people cannot, so the compiled results have been collated for them. The project description says it provides the binaries, edges and supernodes, of n2n that were collected. So this is a distribution point, not a development fork. The code lives elsewhere, in three separate places, and this repository holds what came out of compiling it. The three download routes listed in the README are, in order, the GitHub repository, a Gitee mirror described as faster for China, and a plain web directory described as convenient and uninsured. The wording on that last one is a warning worth taking at face value: ```bash First: https://github.com/lucktu/n2n Second: https://gitee.com/lucktu/n2nb (Faster for China) Third: http://n2n.lucktu.com/n2n/ (Convenient,uninsured) ``` The repository top level lists the platform directories the binaries are organised into: Android/, Linux/, Mac/, Windows/ and iOS/, plus a ZDoc/ directory and a .github/ directory. The licence is GPL-3.0, and the last push was on 2026-08-03 with no GitHub releases, so the commit log is the history. There is also a Docker route, handled through a separate fork of n2n-lucktu by another contributor, with a build readme and doc, and a published image on Docker Hub under zctmdc/n2n. ## Three code lines with three incompatible versioning schemes The most valuable part of the README is a dated changelog, and it is split into three sections because n2n exists in three divergent lines that do not share a version scheme. The first section is for n2n_v2.3, pointing at the lucktu/n2n6 repository. The most recent entry, 2026-08-03, is v2.3_7.2, an update to v2.3_7.2_r287_ea2f439, and it is the one that supports a supernode without IPv6. Before that, 2026-07-13 gave v2.3_6.5, and 2026-06-27 gave v2.3_6.3. The 2025-12-22 entry, v2.3.2.1_f4ecf76, is the one that supports IPv4 and IPv6 and provides a test server. The second section is n2n_v3, pointing at ntop/n2n. Its newest entry is from 2022-05-25, v.3.1.1_r1210, and the notable change in that release is that route and upnp became separate programs. Earlier entries cover v.3.1.0 with upnp support, the official v3.0.0 release, and a 2020-08-12 note that the edge is no longer compatible with the previous one. The third section is n2n_v2, pointing at the 2.8-stable branch, whose newest entry is 2023-06-22, v2.8.2_r558, with speed and stability improvements from the cnn2n project. The two version schemes do not read the same way. The v3 line uses a dotted version followed by an underscore and a revision count, while the v2 lines use a different set of suffixes, and the v2.3 line in the first section uses yet another pattern with a trailing commit hash. Anyone comparing two builds across forks has to read the changelog rather than compare version strings, and the 2020-08-12 note about the edge no longer being compatible with the previous one is the sharpest example of why. ## The v2 changelog reads as a feature history of the edge binary The longest part of the README is the n2n_v2 section, and it is effectively a feature log for the edge command, with entries going back to 2018. The pattern is that each entry adds a flag. In 2018, the edge and supernode could read a configuration file, then a -c parameter was added to the supernode, then configure and autogen.sh were added. In 2019 the -A parameter was added to the edge to increase speed, and the method of AES was modified so it was different from the previous one with the -A option. The 2020 entries are the most informative because they show the compression and encryption flags arriving in a particular order. The -n parameter added the ability to insert Linux routes in n2n, the -A1 through -A5 flags added a sequence of ciphers, with -A4 as chacha20, -A3 as aes-cbc, -A2 as twofish, and -A1 disabling payload encryption. The -z flag enabled lzo1x compression, and a later entry enabled zstd compression while changing z1 to z, in other words replacing the lzo1x option with a zstd one under a new name. The -H flag in the edge added header encryption, and the -D option enabled PMTU discovery. Then the supernode side got its own series, with -t to customise the management port, -u and -g, and later the -d flag, which the README describes as providing AutoIP for the edge and enhancing the management of the supernode. The 2020-08-08 entry is worth reading carefully because it explains a fork. The v.2.7.0_r523 release adds -d in the supernode, provides AutoIP for the edge, and enhances supernode management, and the entry points out that v.2.8.0 has no such feature and says to compile it yourself. The repository therefore provides a modified v.2.7.0_r525 that changes the edge and supernode help output for everyone to use, with the -d flag, documented in a ZDoc entry. ## Test supernodes on four different ports, and the v1 lineage The README lists supernodes for testing, one per code line, each on its own port: ```bash v1 ouno.eu.org:10082 v2s ouno.eu.org:10088 v2 ouno.eu.org:10086 v3 ouno.eu.org:10090 ``` The v1 and v2s entries point at the original meyerd repositories, which is a reminder that n2n started life outside ntop. The From section maps the four lines to their source repositories. Version 1 is the n2n_v1 tree in the meyerd repository, and the v2s line is the n2n_v2 tree in the same place. Version 2 comes from the 2.8-stable branch of ntop/n2n or from lucktu/cnn2n, described as new2. Version 3 is the ntop/n2n repository. The 2018-06-06 entry in the changelog records the moment the project was restarted: The official restart the N2N project, at v2.1.0_r20, and there is no v2.2.0 version, with an upgrade to v2.3.0 in June 2018. For someone evaluating n2n itself, the upshot is that there are at least four distinct protocols in circulation, and the README's own entry for 2020-08-12 says plainly that the edge is no longer compatible with the previous one. The supernode versions and the edge versions have to come from the same line, and the port numbers in the test list are the quickest way to tell which line a given build belongs to. A QQ group is also given, 196588661, with an older number, 256572040, marked as disused. ## What to check before you trust a binary you did not compile The honest caveat about this repository is that it is a collection of artefacts whose provenance you cannot inspect from here. What the repository does give you is a version map. Every build listed in the changelog carries a revision identifier, and in the v2.3 line a trailing commit hash, so a binary in the Linux or Windows directory can be tied back to a specific upstream commit. That is the mitigation: check the changelog entry for the exact build you downloaded, and confirm the revision matches. What it does not give you is a build recipe. The upstream repositories have their own build instructions, and the Docker route in the README is explicitly the way to build it yourself, by forking the n2n-lucktu project and following its build readme and doc. If reproducibility matters to you, that is the path. The GitHub Actions and release-style packaging is also worth noting. The README mentions that the binaries are compiled in CI rather than on a personal machine, which is a better starting point than a laptop, though it is still not the same as reproducing the build yourself. Two final practical points. The 2025-12-22 entry in the v2.3 line points at a public test server, n2n6.ouno.eu.org, which gives you a supernode to try against without running one. And the licence is GPL-3.0, which is what a compiled binary of GPL software must be, so the binaries and the upstream code share terms. For a peer-to-peer VPN that carries your traffic, the security question is not the licence but the cryptography, and the changelog entries above are where the cipher selection for a given build is actually recorded. ## Conclusion lucktu/n2n suits someone who wants to run an n2n network without a compiler toolchain, and the dated changelog per fork is worth more than the binaries for anyone trying to work out which code line they should be on. It does not suit you as a source of truth for n2n itself, since each fork upstream is where the code and the real changelog live, and it does not suit you if you need reproducible builds, because these are binaries someone else compiled. Before you use one, read the entry for the exact build in the changelog, since the forks are not interchangeable, and note that the third download mirror is described in the README as convenient and uninsured. ## FAQ ### What does the lucktu/n2n repository contain? Compiled binaries of the n2n edge and supernode for Linux, Windows, macOS, Android and iOS, collected because compiling n2n is a technical job many people cannot do. The top level holds Android/, Linux/, Mac/, Windows/, iOS/ and ZDoc/ directories. ### Which n2n version should I use according to the changelog? The README tracks three lines separately: n2n_v2.3 from the lucktu/n2n6 repository, where the newest entry is v2.3_7.2 from 2026-08-03 supporting a supernode without IPv6; n2n_v3 from ntop/n2n, whose newest entry is v.3.1.1_r1210 from 2022-05-25; and n2n_v2 from the 2.8-stable branch, whose newest entry is v2.8.2_r558 from 2023-06-22. ### Where can I download the n2n binaries? From the GitHub repository at lucktu/n2n, from a Gitee mirror at lucktu/n2nb which is described as faster for China, or from a plain web directory at n2n.lucktu.com which the README describes as convenient and uninsured. ### Can I run n2n without setting up a supernode? For testing, yes. The README lists public test supernodes on separate ports for each code line, including ouno.eu.org:10086 for the v2 line and ouno.eu.org:10090 for v3, and the 2025-12-22 entry for the v2.3 line also names a test server at n2n6.ouno.eu.org. ## Sources - [Issues](https://github.com/lucktu/n2n/issues) - [License: GPL-3.0](https://github.com/lucktu/n2n/blob/master/LICENSE) - [lucktu/n2n on GitHub](https://github.com/lucktu/n2n) - [README](https://github.com/lucktu/n2n/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lucktu-n2n