Instructions to add vanilla wireguard client

[ptman]

Can it be done if the IP doesn't change?

[mcginty]

Hey @ptman, I'm assuming by vanilla wireguard you mean connecting to innernet with only wg/netlink commands?

The invitation system would be the most complicated part to address without the innernet client, but it's just a simple HTTP API so you can most certainly write your own client in bash with curl and wg and get most of the way there :).

Let's say you already redeemed the invitation though so you don't need to re-implement that negotiation. Then you're in much better shape to use vanilla WireGuard to connect to the network, you could basically convert the contents of /etc/innernet/[interface].conf (the static contents like your private key and address) and /var/lib/innernet/[interface].json (the dynamic contents like your peers list and CIDR list) to a standard WireGuard config format and then use wg-quick or your own initialization script from there.

[ptman]

I was mostly thinking about non-Linux. Android and iOS. Windows. BSDs should be possible with current client, since it works on macOS?

Keeping the config up to date would be the biggest issue once you get it going. Innernet is pure mesh, right? The central/server node doesn't do fallback star routing for road warrior nodes?

Anyway, extremely cool project.

[ptman]

Rust support for 32bit arm is also not tier-1. This may help old raspberry pi (pre-rpi3, or using 32-bit raspbian) deployments.

[mcginty]

I was mostly thinking about non-Linux. Android and iOS. Windows. BSDs should be possible with current client, since it works on macOS?

I don't imagine BSD works 100% right now, but it's probably not far off from being well-supported!

Keeping the config up to date would be the biggest issue once you get it going. Innernet is pure mesh, right? The central/server node doesn't do fallback star routing for road warrior nodes?

That's right - in WebRTC terminology, innernet does STUN, not TURN - it doesn't proxy any traffic for peers where simple UDP NAT holepunching isn't possible.

Anyway, extremely cool project.

Thanks! and thanks for participating.

[HarvsG]

That's right - in WebRTC terminology, innernet does STUN, not TURN - it doesn't proxy any traffic for peers where simple UDP NAT holepunching isn't possible.

Would be cool to allow for road-warrior devices as 'spokes' off a node on the mesh to be added that send some or all of their traffic over the tunnel and then have to routed by the node they connect to.

It would just be a matter of adding a peer to the desired node then making sure the client.conf either has AllowedIPs=0.0.0.0/0 or AllowedIPs=<up to date list of all CIDRs they should have access to>. The latter would go out of date when a new CIDR is added to the mesh of course.

It could be specified that any peer added with /32 should be treated as a 'road warrior`

[codegamc]

Hey @mcginty would it be possible to document the API and invite file format?

it's just a simple HTTP API so you can most certainly write your own client in bash with curl and wg and get most of the way there :).

That would make this process so much easier. I'd be interested in writing an alternative client and documentation would really boost this effort.

[mcginty]

@codegamc Yeah, I think now's a good time to document the protocol - I'll add that as a task for myself.

[nettybun]

Hello!

I've been thinking how I could use innernet with a small group of friends to share a "cloud" server (private/mesh-only not on the internet). Linux+Mac autoconfiguration seems good to go for innernet but I'm curious about our phones - can you imagine a way that Android and iOS could connect with only the official wireguard app? I'm still trying to wrap my head around the network topology and understand what is even possible with innernet's design, I've read the README and all the relevant GitHub issues but am still not sure how vanilla clients would work.

Based on your above comment #3 (comment) there should be a way to construct a wireguard config to add to a phone. Likely a person's laptop would "accept" an invitation meant for our phone, but store the resulting configs + private-key into a new wireguard config instead of installing it to the laptop. This new config would then be moved onto the phone... Would that be possible? (I understand this is not implemented)

Previously I've sent wireguard configs to phones in order to connect them to AzireVPN. They have https://www.azirevpn.com/cfg/wireguard which creates an "invitation" of sorts; they create a ZIP file of wireguard configs, one per VPN server.

Instead, I guess a resulting innernet wireguard config would be simply a single file with a [Peer] block for every device (full-mesh).

I understand this doesn't scale or provide a way to do changes but we collectively only have 10 devices so I'm more interested in this as a POC 😄

Thank you for all your work on this amazing project and for clarifying how it works! You're leading networking to a brighter future.

---

FWIW I'm planning to get around the DNS problem by hardcoding each peer's wireguard IP into my DNS server so there's a public DNS record like sydney.site.ca >> 10.0.0.2. Again, I don't need this to scale, it's mostly a POC.

[boehs]

backlink #2

[bj0]

Has anyone done this? I would like to try to use innernet for a small network but one node is on windows and one on android, so the only thing holding me back is some sort of vanilla node support.

Since this issue is pretty old I was hoping someone has figured out how to get it to work.