Initial version of the `firezone-connection` crate. To begin with, we
only establish a connection in a LAN, i.e. no hole-punching, no STUN or
TURN servers, just host candidates. As such, a lot of this PR is just
scaffolding for setting up the test environment and the actual
`ConnectionPool` implementation.
For the curious, I've left some TODOs where I am going to attempt
extending the implementation once we start dealing with STUN and TURN
servers.
I also extended CI to run these tests.
... and move its methods into ResourceDescription.
This was a TODO from some pull request in the last few days. I assume
the goal is to share this function between all clients if needed. It
doesn't reduce the number of lines of code, since I could have removed
ResourceDisplay and done this on-the-fly when building the systray menu,
as an alternative.
Fix for #2956 this is achieved by refreshing access to every resource
every 5 minutes.
There's still an open question for this PR:
When the gateway resolves an ip the gateway allows access to a DNS
resource it resolves the address and allow access to that ip for that
client.
Right now, until the access for that resource doesn't expire that access
isn't revoked.
We could change it so that we require the client to refresh such
access(with this PR those refresh queries are already being made every 5
minutes) every x minutes on top of the `expires_at` or we can keep
`expires_at` as to mean "allow access until `expires_at` for whatever
this resource resolves to".
cc @jamilbk @AndrewDryga
Previously, we just assumed that the domain in the query is a subdomain
of the resource but a malicious actor can hijack that field to access
domains that doesn't correspond to that resource.
With this patch we don't even resolve the address for unrelated domains.
Fixes#2470, now for linux it looks like:
```
Alpine Linux/3.19.0 (x86_64;5.15.133.1-microsoft-standard-WSL2;) connlib/1.0.0
```
For macos it looks like:
```
Mac OS/13.4.1 (arm64;22.5.0;) connlib/1.0.0
```
and this is how it looks on android:
```
Android/Unknown 6.1.23-android14-4-00257-g7e35917775b8-ab9964412 connlib/1.0.0
```
note: seems like in android emulator at least we can't get the
architecture so easily
Should fix#2880
The way I do it is after ~10 seconds dropping the
`gateway_awaiting_connection` and let the client try the connection
again, depending on upper layer, I think this is fine since the cases
where this happens is unlikely.
It's hard to test thoroughly but I'll test with bad-condition
simulators, [pumba](https://github.com/alexei-led/pumba) seems
promising. In the meantime I'm still creating the PR so that I can have
it reviewed.
Edit: Using Pumba with different % of packet loss things seems to go
well, and connections are actually established even if the packets are
loss. (Making a note that we should integrate pumba with our CI)
I found out `keyring-rs` wasn't doing "firezone/token" internally, so
our credential was just "token", which is too generic. I changed it to
use our domain so it's "dev.firezone.client/token".
Partially fixes#2920
As explained in
https://github.com/firezone/firezone/issues/2920#issuecomment-1861642550
in the future we should change the way we resolve DNS queries in the
gateway to properly handle HTTPS record types.
With this patch this is what happens to an HTTPS query while firezone is
running:
```
kdig -t HTTPS ifconfig.net
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 15773
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
;; QUESTION SECTION:
;; ifconfig.net. IN HTTPS
;; Received 30 B
;; Time 2023-12-18 18:34:23 -03
;; From 100.100.111.1@53(UDP) in 0.6 ms
```
Fixes#2948
So it seems that it's easiest just to use an old-fashioned semver
string. This means we'll need to keep a version matrix in the docs of
which components are supported and for how long, but it's better than
having different version schemes for different Firezone components
altogether.
Automatically write the wintun.dll file on startup and then detect
whether we need to elevate to admin privileges.
I check for privileges by making a test tunnel, so I did #2758 as part
of this, which bundles the DLL inside the exe, and then the exe deploys
it.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Don't need them any more. `build-tauri` is about 5 minutes faster
without the permissions test, since it had to be a separate project /
workspace entirely and rebuilt a bunch of stuff. That's a reason I
prefer subcommands. For some reason sccache didn't seem to do much for
it. This is also a flaw in Tauri, I couldn't figure out any proper way
to keep a Tauri project inside the examples dir of another Tauri
project. With two non-Tauri apps it's easier and probably wouldn't add
much build time.
Prevent the edge case where our DNS sentinel could be used as a fallback
resolver. I didn't observe this in the wild, but we should avoid it in
case.
---------
Co-authored-by: Gabi <gabrielalejandro7@gmail.com>
Stacked on PR #2888
This will fix#2878 by setting some Windows security permissions to let
non-admin clients connect to a named pipe server owned by an admin
process.
It should also give us a path to fix 2808 (If I link it, Github assumes
this PR closes that issue?), since it'll be our own code instead of
tauri-plugin-deep-link, and we can just choose not to panic. I'm using
Tokio's `named_pipe` module where that panic happens, and Tokio is good
about just returning Results instead of panicking.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
This fixes#2503
Also:
* decouples data-plane and control-plane on the gateway
* fixes a thing were a client would stop retrying connecting to a
resource if it failed too many times
* add all routes on start instead of on a per-route basis
Stacked on PR #2883
There will be more changes after this PR, these features are still
broken:
- Can't change filter at runtime yet, you have to restart the client app
- connlib and GUI are sending logs to the same connlib logs files, they
should be separated
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
This reduces the failover time by depending on webrtc's keepalive
instead of wireguard's.
We have much more control over that, since boringtun doesn't bubble up
any of the keepalives timeout(only a trace warning).
In the a next commit, when things are more stable, we should just get
rid of wireguard's keep alive. When we remove webrtc we will build our
own.
Events based on `keepalive` timeouts are key to our failover system, so
we **need** it.
Draft because it's built on top of #2891 (which is completely separate
code but without that the failover just doesn't work correctly)
<img width="1552" alt="Screenshot 2023-12-12 at 11 29 43 PM"
src="https://github.com/firezone/firezone/assets/167144/d517c830-64a8-462d-8cb5-c41835fa2059">
Found a reliable way to return default system DNS resolvers on iOS and
macOS. Even if this method is not perfect, I think it's still worth
pursuing because:
* Many administrators will set an upstream resolver in the portal anyway
(bypassing client system resolvers)
* It unifies our Split DNS approach across platforms (assuming we can
query the default system resolvers on Windows), allowing connlib to
intercept all DNS queries on all platforms. This opens the door for some
interesting feature possibilities in the area of malicious query
blocking. This also makes DNS bugs easier to investigate because there's
only one codepath for packets to take. See
https://github.com/firezone/firezone/issues/2859
Draft because it needs more testing and I need to figure out the
`RustVec<RustString>` type for the Swift -> Rust FFI.
Refs #2713
When a peer expired the os might have cached the old internal ips that
we used, then with a new peer we were assigning new ips and that cached
ip might have been wrong, then the tunnel would be in state where it
would send the wrong response to this ips.
With this PR we try to always reuse the old ip if there's any available.
Previously, we just expected the portal to disconnects us and 401 on the
retry, right now we harden that behaviour by also just disconnecting
when token expiration.
This seems to work, there's another part to this which is not only
handling the replies but also handling the message generated by the
portal, I'll implement that when I can easily test expirying tokens, for
now this makes the client much more stable.
just silly but important mistake 😛fixes#2858 and #2859 (though there might be an additional edge case in
#2859 where the upstream server is set as a dns, though it seems to work
some further testing would be good)
At present, the definition of `Device` is heavily nested with
conditional code. I've found this hard to understand and navigate.
Recent refactorings now made it possible to remove a lot of these layers
so we primarily deal with two concepts:
- A `Device` which offers async read and non-blocking write functions
- A `Tun` abstraction which is platform-specific
Instead of dedicated modules, I chose to feature-flag individual
functions on `Device` with `#[cfg(target_family = "unix")]` and
`#[cfg(target_family = "windows")]`. I find this easier to understand
because the code is right next to each other.
In addition, changing the module hierarchy of `Device` allows us to
remove `async` from the public API which is only introduced by the use
of `rtnetlink` in Linux. Instead of making functions across all `Tun`
implementations `async`, we embed a "worker" within the `linux::Tun`
implementation that gets polled before `poll_read`.
---------
Co-authored-by: Gabi <gabrielalejandro7@gmail.com>
It'll show UAC when you first run the app. After that we can open and
close the VPN network adapter without showing more UAC dialogs since we
have sudo powers.
Fixes: #2854.
Note: this is ready for review but reproducing the bug that triggered
the fix takes ~1 hour or so, so I would like to wait to check that's
fixed.
Can be reviewed meanwhile.
