Open jrop opened 3 years ago
I've just finished installing this in WSL, so windows is technically supported. Having it work on the host OS would be great though.
@Eeems That is good to know. The use-case I'm thinking of, however, would be along the lines of giving this to a friend who may not be technically advanced and not even know about the existence of WSL.
They'd need to support the wireguard Go implementation which is user space and what tailscale uses on non linux devices.
@Eeems that's great to hear! Thanks for reporting back on that here.
None of us at tonari are Windows users at the moment which is why it's unsupported now, but I'm interested in adding it. There's no timeframe on that, but I'd be happy to help anyone who's interested in submitting a PR.
In case anybody comes here and wants instructions on how to install in WSL: https://eeems.website/innernet-in-wsl
What other things would have to be done to run on Windows? I see there are already some things in the wgctrl
crates for not(target_os = "linux")
.
I'd really like this feature as well. We use Wireguard in our company, but like the security and manageability this offers.
Is there a way that importing the configuration data to other wireguard client can work. I have on a windows workstation Wireguard client installed which uses wireguard-go. But when i try to import the data, the handshake keeps failing.
@readall Did you ever get this working?
There are many solutions out there, but less and less are supporting Windows 7 32 bit clients. :-( (And by that, accelerating this ... )
If this could be an alternative to OpenVPN, it would be really great! 👍
So I'm definitely not an expert on Rust packages, but trying to run cargo install --git https://github.com/tonarino/innernet --tag v1.6.1 client
on Windows only starts to error out when compiling wireguard-control
.
The first error occurs on line 7 of wireguard-control/src/backends/userspace.rs
, which specifically references unix:
error[E0433]: failed to resolve: could not find `unix` in `os`
--> wireguard-control\src\backends\userspace.rs:7:9
|
7 | os::unix::net::UnixStream,
| ^^^^ could not find `unix` in `os`
|
The remaining four errors all occur in wireguard-control/src/device.rs
and revolve around a specific value that apparently doesn't exist in Rust libc on Windows:
error[E0425]: cannot find value `IFNAMSIZ` in crate `libc`
--> wireguard-control\src\device.rs:115:40
|
115 | type RawInterfaceName = [c_char; libc::IFNAMSIZ];
| ^^^^^^^^ not found in `libc`
(Only showed one for brevity, the other occurrences are on lines 134, 138, and 201)
Running the command with --keep-going
produces no further errors, which I think implies that if wireguard-control
were able to compile for Windows, innernet would work.
On Windows, it seems WG is using named pipes for IPC: https://github.com/WireGuard/wireguard-go/blob/master/ipc/uapi_windows.go#L62 Sadly it's using GOB (the Go-native encoding,) but there are Rust libraries for it.
IFNAMSIZ
is just the max size of interface names. On Windows, wireguard-go uses wintun, which has const AdapterNameMax = 128
.
@ann4belle @tommie thanks for looking into this! It would definitely be nice to support windows, the only reason we don't at the moment is because no one on our team uses windows regularly. Still, PRs are welcome and maybe one day I'll pick up a windows machine to be able to test things.
I saw your blog post broadcasted on the Nebula Slack, and I must say, I am extremely interested in this project. Also, I'm a Rust fanboy, so this project gets bonus points there as well 😛 .
Now for my question: Is Windows support planned? I mostly use Linux/macOS, but there are instances where I want to connect with a Windows machine as well.