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.
It doesn't run with `--example` because Tauri's build process doesn't
seem to be compatible with that.
But it does build the permissions test exe in CI. I might change that a
general test exe later so that I don't have to add more build targets.
It adds about 5 minutes to the CI, sccache only seems to speed up the
build for the 2nd exe a tiny bit.
This PR changes the protocol and adds support for DNS subdomains, now
when a DNS resource is added all its subdomains are automatically
tunneled too. Later we will add support for `*.domain` or `?.domain` but
currently there is an Apple split tunnel implementation limitation which
is too labor-intensive to fix right away.
Fixes#2661
Co-authored-by: Andrew Dryga <andrew@dryga.com>
