HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tonarino
innernet
Rust2021–2026
tonarino / innernet

innernet

A private network system that uses WireGuard under the hood.

25Distinct people
29Mentions
0Explicit recommenders
5.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A private network system that uses WireGuard under the hood.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year29 dated mentions

Observed mentions: 2021-04-15 18:36:41 UTC to 2026-02-02 16:08:48 UTC.

0369122021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC12111
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC1019
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC303
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC312
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC110

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
innernet A private network system that uses WireGuard under the hood. See the announcement blog post for a longer-winded explanation. innernet is similar in its goals to Slack's nebula or Tailscale, but takes a bit of a different approach. It aims to take advantage of existing networking concepts like CIDRs and the security properties of WireGuard to turn your computer's basic IP networking into more powerful ACL primitives. innernet is not an official WireGuard project, and WireGuard is a registered trademark of Jason A. Donenfeld. This has not received an independent security audit, and should be considered experimental software at this early point in its lifetime. Usage Server Creation Every innernet network needs a coordination server to manage peers and provide endpoint information so peers can directly connect to each other. Create a new one with sudo innernet-server new The init wizard will ask you questions about your network and give you some reasonable defaults. It's good to familiarize yourself with network CIDRs as a lot of innernet's access control is based upon them. As an example, let's say the root CIDR for this network is 10.60.0.0/16. Server initialization creates a special "infra" CIDR which contains the innernet server itself and is reachable from all CIDRs on the network. Next we'll also create a humans CIDR where we can start adding some peers. sudo innernet-server add-cidr <interface> For the parent CIDR, you can simply choose your network's root CIDR. The name will be humans, and the CIDR will be 10.60.64.0/24 (not a great example unless you only want to support 256 humans, but it works for now...). By default, peers which exist in this new CIDR will only be able to contact peers in the same CIDR, and the special "infra" CIDR which was created when the server was initialized. A typical workflow for creating a new network is to create an admin peer from the innernet-server CLI, and then continue using that admin peer via the innernet client CLI to add any further peers or network CIDRs. sudo innernet-server add-peer <interface> Select the humans CIDR, and the CLI will automatically suggest the next available IP address. Any name is fine, just answer "yes" when asked if you would like to make the peer an admin. The process of adding a peer results in an invitation file. This file contains just enough information for the new peer to contact the innernet server and redeem its invitation. It should be transferred securely to the new peer, and it can only be used once to initialize the peer. You can run the server with innernet-server serve <interface>, or if you're on Linux and want to run it via systemctl, run systemctl enable --now innernet-server@<interface>. If you're on a home network, don't forget to configure port forwarding to the Listen Port you specified when creating the innernet server. Peer Initialization Let's assume the invitation file generated in the steps above have been transferred to the machine a network admin will be using. You can initialize the client with sudo innernet install /path/to/invitation.toml You can customize the network name if you want to, or leave it at the default. innernet will then connect to the innernet server via WireGuard, generate a new key pair, and register that pair with the server. The private key in the invitation file can no longer be used. If everything was successful, the new peer is on the network. You can run things like sudo innernet list or sudo innernet list --tree to view the current network and all CIDRs visible to this peer. Since we created an admin peer, we can also add new peers and CIDRs from this peer via innernet instead of having to always run commands on the server. Adding Associations between CIDRs In order for peers from one CIDR to be able to contact peers in another CIDR, those two CIDRs must be "associated" with each other. With the admin peer we created above, let's add a new CIDR for some theoretical CI servers we have. sudo innernet add-cidr <interface> The name is ci-servers and the CIDR is 10.60.64.0/24, but for this example it can be anything. For now, we want peers in the humans CIDR to be able to access peers in the ci-servers CIDR. sudo innernet add-association <interface> The CLI will ask you to select the two CIDRs you want to associate. That's all it takes to allow peers in two different CIDRs to communicate! You can verify the association with sudo innernet list-associations <interface> and associations can be deleted with sudo innernet delete-associations <interface> Enabling/Disabling Peers For security reasons, IP addresses cannot be re-used by new peers, and therefore peers cannot be deleted. However, they can be disabled. Disabled peers will not show up in the list of peers when fetching the config for an interface. Disable a peer with sudo innernet disable-peer <interface> Or re-enable a peer with sudo innernet enable-peer <interface> Specifying a Manual Endpoint The innernet server will try to use the internet endpoint it sees from a peer so other peers can connect to that peer as well. This doesn't always work and you may want to set an endpoint explicitly. To set an endpoint, use sudo innernet override-endpoint <interface> You can go back to automatic endpoint discovery with sudo innernet override-endpoint -u <interface> Setting the Local WireGuard Listen Port If you want to change the port which WireGuard listens on, use sudo innernet set-listen-port <interface> or unset the port and use a randomized port with sudo innernet set-listen-port -u <interface> Remove Network To permanently uninstall a created network, use sudo innernet-server uninstall <interface> Use with care! Security recommendations If you're running a service on innernet, there are some important security considerations. Enable strict Reverse Path Filtering (RFC 3704) Strict RPF prevents packets from other interfaces from having internal source IP addresses. This is not the default on Linux, even thoug
Read the full README on GitHub

What Hacker News says

29 sources
In the self-hosted space, I've been really enjoying playing around with decentralized encrypted overlay mesh networks like Nebula. Here's the current list of my faves (all Wireguard based). Open-source projects not-quite-prod-ready: - WebMesh: Golang, decentralized nodes https://github.com/webmeshproj - InnerNet: Rust, with subnet ACLs https://github.com/tonarino/innernet - Wesher: Golang, simple mesh with pre-shared key https://github.com/costela/wesher - Wiresmith: Rust, auto-configs clients into a mesh https://github.com/svenstaro/wiresmith Open source projects with company-backed SaaS offerings: - Netbird: Golang, full-fledged solution (desktop clients, DNS, SSO, STUN/TURN, etc) https://github.com/netbirdio/netbird - Netmaker: Golang, full-fledge solution https://github.com/gravitl/netmaker Honorable mention: - SuperHighway84
Read the rest
- more of a Usenet-inspired darknet, but I love the concept + the author's personal website: https://github.com/mrusme/superhighway84 https://xn--gckvb8fzb.com/superhighway84
In Would we still create Nebula today?
It looks like the authentication rests upon looking up the owner of the incoming packet's (tailnet) IP address[0]. Does anyone know whether they have measures in place to protect against IP spoofing? Background: The OP reminded me of innernet (a Tailscale alternative) which was presented here on HN last year[1] and which is – at least in principle – vulnerable to IP spoofing[2] because it assumes incoming IP packets (with a WireGuard IP address as "source") must originate from WireGuard's wg0 network interface and cannot e.g. originate from eth0 – which, unfortunately, is not the case on most systems. As far as I can tell from briefly looking at tsnet[3] (which is what their authentication proxy[4] uses under the hood), tsnet runs WireGuard in user space(?), so this should prevent IP spoofing. Can anyone confirm this? [0] https://tailscal
Read the rest
In Tailscale Authentication for Minecraft

Showing the 15 most recent of 29 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.