Closes#6989
- The tunnel daemon (IPC service) now explicitly sets the ID file's
perms to 0o640, even if the file already exists.
- The GUI error is now non-fatal. If the file can't be read, we just
won't get the device ID in Sentry.
- More specific error message when the GUI fails to read the ID file
We attempted to set the tunnel daemon's umask, but this caused the smoke
tests to fail. Fixing the regression is more urgent than getting the
smoke tests to match local debugging.
---------
Co-authored-by: _ <ReactorScram@users.noreply.github.com>
This has been a long-standing issue.
The base PR fixes the issue for Firefox, and apparently all other
browsers will _not_ change your DNS server, only opportunistically
enable DoH if it finds your current servers to support it.
Bumps the npm_and_yarn group in /website with 1 update:
[micromatch](https://github.com/micromatch/micromatch).
Updates `micromatch` from 4.0.7 to 4.0.8
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/micromatch/micromatch/releases">micromatch's
releases</a>.</em></p>
<blockquote>
<h2>4.0.8</h2>
<p>Ultimate release that fixes both CVE-2024-4067 and CVE-2024-4068. We
consider the issues low-priority, so even if you see automated scanners
saying otherwise, don't be scared.</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/micromatch/micromatch/blob/master/CHANGELOG.md">micromatch's
changelog</a>.</em></p>
<blockquote>
<h2>[4.0.8] - 2024-08-22</h2>
<ul>
<li>backported CVE-2024-4067 fix (from v4.0.6) over to 4.x branch</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="8bd704ec0d"><code>8bd704e</code></a>
4.0.8</li>
<li><a
href="a0e68416a4"><code>a0e6841</code></a>
run verb to generate README documentation</li>
<li><a
href="4ec288484f"><code>4ec2884</code></a>
Merge branch 'v4' into hauserkristof-feature/v4.0.8</li>
<li><a
href="03aa805217"><code>03aa805</code></a>
Merge pull request <a
href="https://redirect.github.com/micromatch/micromatch/issues/266">#266</a>
from hauserkristof/feature/v4.0.8</li>
<li><a
href="814f5f70ef"><code>814f5f7</code></a>
lint</li>
<li><a
href="67fcce6a10"><code>67fcce6</code></a>
fix: CHANGELOG about braces & CVE-2024-4068, v4.0.5</li>
<li><a
href="113f2e3fa7"><code>113f2e3</code></a>
fix: CVE numbers in CHANGELOG</li>
<li><a
href="d9dbd9a266"><code>d9dbd9a</code></a>
feat: updated CHANGELOG</li>
<li><a
href="2ab13157f4"><code>2ab1315</code></a>
fix: use actions/setup-node@v4</li>
<li><a
href="1406ea38f3"><code>1406ea3</code></a>
feat: rework test to work on macos with node 10,12 and 14</li>
<li>Additional commits viewable in <a
href="https://github.com/micromatch/micromatch/compare/4.0.7...4.0.8">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/firezone/firezone/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Ubuntu 20.04 ARM doesn't work because we're building on 22.04 in CI
against a newer glibc
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
We want to associate additional device information for the device
verification, these are all parameters that tries to uniquely identify
the hardware.
For that reason we read system information and send it as part of the
query params to the portal, that way the portal can store this when
device is verified and match against that later on.
These are the parameters according to each platform:
|Platform|Query Field|Field Meaning|
|-----|----|-----|
|MacOS|`device_serial`|Hardware's Serial|
|MacOS| `device_uuid`|Hardware's UUID|
|iOS|`identifier_for_vendor`| Identifier for vendor, resets only on
uninstall/install|
|Android|`firebase_installation_id`| Firebase installation ID, resets
only on uninstall/install|
|Windows|`device_serial`|Motherboard's Serial|
|Linux|`device_serial`|Motherboard's Serial|
Fixes#6837
Bumps [framer-motion](https://github.com/framer/motion) from 11.3.31 to
11.9.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/framer/motion/blob/main/CHANGELOG.md">framer-motion's
changelog</a>.</em></p>
<blockquote>
<h2>[11.9.0] 2024-09-27</h2>
<h3>Added</h3>
<ul>
<li>Mini <code>animate</code> and <code>useAnimate</code>
functions.</li>
</ul>
<h2>[11.8.0] 2024-09-25</h2>
<h3>Added</h3>
<ul>
<li>Easing functions now get compiled into <code>linear()</code> easings
when animating via WAAPI.</li>
</ul>
<h2>[11.7.0] 2024-09-25</h2>
<h3>Added</h3>
<ul>
<li>Added support for custom animation generators via
<code>type</code>.</li>
</ul>
<h2>[11.6.0] 2024-09-24</h2>
<h3>Added</h3>
<ul>
<li>Added <code>info</code> and element tracking to
<code>scroll</code>.</li>
<li>Added <code>steps</code> easing.</li>
</ul>
<h3>Changed</h3>
<ul>
<li>Values added to <code>will-change</code> now stay there for their
lifespan to prevent GPU thrashing and weird Safari subpixel
jitters.</li>
</ul>
<h2>[11.5.6] 2024-09-20</h2>
<h3>Fixed</h3>
<ul>
<li>Ensuring updating motion values during <code>render</code> doesn't
lock rendering for an element.</li>
</ul>
<h2>[11.5.5] 2024-09-19</h2>
<h3>Fixed</h3>
<ul>
<li>Changed values of child variants now animate even when the parent
variant name hasn't changed.</li>
</ul>
<h2>[11.5.4] 2024-09-05</h2>
<h3>Fixed</h3>
<ul>
<li>Improving tree-shakability.</li>
</ul>
<h2>[11.5.3] 2024-09-05</h2>
<h3>Fixed</h3>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="33fbeb904c"><code>33fbeb9</code></a>
v11.9.0</li>
<li><a
href="77077d10f2"><code>77077d1</code></a>
Updating changelog</li>
<li><a
href="c3d7fd4703"><code>c3d7fd4</code></a>
Featherweight API (<a
href="https://redirect.github.com/framer/motion/issues/2814">#2814</a>)</li>
<li><a
href="b544cce137"><code>b544cce</code></a>
Enlarging bundlesize</li>
<li><a
href="bff50291f7"><code>bff5029</code></a>
v11.8.0</li>
<li><a
href="94f4d7c09d"><code>94f4d7c</code></a>
Updating changelog</li>
<li><a
href="c14c9dac14"><code>c14c9da</code></a>
Support for <code>linear()</code> easing function (<a
href="https://redirect.github.com/framer/motion/issues/2812">#2812</a>)</li>
<li><a
href="bc91591aad"><code>bc91591</code></a>
Updating filesize</li>
<li><a
href="aa6f494dfb"><code>aa6f494</code></a>
v11.7.0</li>
<li><a
href="b716a433d1"><code>b716a43</code></a>
Updating changelog</li>
<li>Additional commits viewable in <a
href="https://github.com/framer/motion/compare/v11.3.31...v11.9.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps
[@types/react](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/react)
from 18.3.3 to 18.3.10.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/react">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Closes#6873
The issue seems to be a race between flushing Sentry in the GUI process
and shutting down Firezone in the tunnel daemon (IPC service).
With this change, the GUI waits to hear `DisconnectedGracefully` from
the tunnel daemon before flushing Sentry, and the issue is prevented.
Adding the new state and new IPC message required small changes in
several places
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Within `snownet` - `connlib`'s connectivity library - we use ICE to set
up a UDP "connection" between a client and a gateway. UDP is an
unreliable transport, meaning the only way how can detect that the
connection is broken is for both parties to constantly send messages and
acknowledgements back and forth. ICE uses STUN binding requests for
this.
In the default configuration of `str0m`, a STUN binding is sent every
3s, and we tolerate at most 9 missing responses before we consider the
connection broken. As these responses go missing, `str0m` halves this
interval, which results in a total ICE timeout of around 17 seconds. We
already tweak these values by reducing the number of requests to 8 and
setting the interval to 1.5s. This results in a total ICE timeout of
~10s which effectively means that there is at most a 10s lag between the
connection breaking and us considering it broken at which point new
packets arriving at the TUN interface can trigger the setup of a new
connection with the gateway.
Lowering these timeouts improves the user experience in case of a broken
connection because the user doesn't have to wait as long before they can
access their resources again. The downside of lowering these timeouts is
that we generate a lot of background noise. Especially on mobile
devices, this is bad because it prevents the CPU from going to sleep and
thus simply being signed into Firezone will drain your battery, even if
you don't use it.
Note that this doesn't apply at all if the client application on top
detects a network change. In that case, we hard-reset all connections
and instantly create new ones.
We attempted to fix this in #5576 by closing idle connections after 5
minutes. This however created new problems such as #6778.
The original problem here is that we send too many STUN messages as soon
as a connection is established. Simply increasing the timeout is not an
option because it would make the user experience really bad in case the
connection actually drops for reasons that the client app can't detect.
In this patch, we attempt to solve this in a different way: Detecting a
broken connection is only critical if the user is actively using the
tunnel (i.e. sending traffic). If there is no traffic, it doesn't matter
if we need longer to detect a broken connection. The user won't notice
because their phone is probably in their pocket or something.
With this patch, we now implement the following behaviour:
- A connection is considered idle after 10s of no application traffic.
- On idle connections, we send a STUN requests every 60s
- On idle connections, we wait for at most 4 missing responses before
considering the connection broken.
- Every connection will perform a client-initiated WireGuard keep-alive
every 25s, unless there is application traffic.
These values have been chosen while considering the following sources:
1. [RFC4787,
REQ-5](https://www.rfc-editor.org/rfc/rfc4787.html#section-12) requires
NATs to keep UDP NAT mappings alive for at least 2 minutes.
2.
[`conntrack`](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.rst)
adopts this requirement via the `nf_conntrack_udp_timeout_stream`
configuration.
3. 25s is the default keep-alive of the WireGuard kernel module.
In theory the WireGuard keep-alive itself should be good enough to keep
all NAT bindings alive. In practice, missed keep-alives are not exposed
by boringtun (the WireGuard implementation we rely on) and thus we need
the additional STUN keep-alives to detect broken connections. We set
those somewhat conservatively to 60s.
As soon as the user triggers new application traffic, these values are
reverted back to their defaults, meaning even if the connection died
just before the user is starting to use it again, we will know within
the usual 10s because we are triggering new STUN requests more often.
Note that existing gateways still implement the "close idle connections
after 5 minutes" behaviour. Customers will need to upgrade to a new
gateway version to fully benefit from these new always-on, low-power
connections.
Resolves: #6778.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Refs #6138
Sentry is always enabled for now. In the near future we'll make it
opt-out per device and opt-in per org (see #6138 for details)
- Replaces the `crash_handling` module
- Catches panics in GUI process, tunnel daemon, and Headless Client
- Added a couple "breadcrumbs" to play with that feature
- User ID is not set yet
- Environment is set to the API URL, e.g. `wss://api.firezone.dev`
- Reports panics from the connlib async task
- Release should be automatically pulled from the Cargo version which we
automatically set in the version Makefile
Example screenshot of sentry.io with a caught panic:
<img width="861" alt="image"
src="https://github.com/user-attachments/assets/c5188d86-10d0-4d94-b503-3fba51a21a90">
Currently, our changelog components have a lot of duplication.
Additionally, keeping a "commented out" `Entry` around leads to many
merge conflicts because the formatter doesn't pick up code within
comments.
To fix this, we introduce an `Unreleased` components that doesn't render
its children. Furthermore, we move the `<ul>` into the `Entry`
components to avoid duplicating it for every changelog entry.
Currently, the order in which connlib matches against the patterns of
DNS resources is not specified. We simply iterate over all patterns and
take the first one that matches. Due to the iteration order of
`HashMap`s, this also isn't deterministic.
With this patch, we introduce a defined order in which we attempt to
match a particular domain against the defined DNS resources:
- Resources without wildcards are always prioritised over wildcard
domains
- Single-char wildcards (`?`) take priority over label wildcards (`*`)
- Label wildcards (`*`) take priority over catch-all wildcards (`**`)
By matching against the DNS resources in a defined order, we ensure that
DNS resources that overlap always resolve to the most specific resource.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
When deciding which interface we are going to use for connecting to the
portal API, we need to filter through all adapters on Windows and
exclude our own TUN adapter to avoid routing loops. In addition, we also
need to filter for only online adapters, otherwise we might pick one
that is not actually routable.
Resolves: #6802.
Closes#6791
We weren't closing the connlib session immediately when we get
`on_disconnect`, this patch fixes that.
This passes the manual test established in #6792. I also cycled through
sign-in, close, open, sign-out, and it looks fine.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Fix#6781Fix#6375
The problem was that browsers in iOS(and possible other OSes) queries
for A, AAAA and HTTPS, and we correctly intercept A and AAAA.
Correctly intercepting HTTPS queries is more tricky since we need the
server's alpn, before this PR we were just forwarding those and then the
response back but the problem with that is that it'd return the real IP
for the service instead of our proxy IP.
So to quickly fix this we simply blackhole the query so the browser
never use that response.
In the future an improvement over this would be to intercept the
response instead of the query and mangle the ips there.
---------
Signed-off-by: Gabi <gabrielalejandro7@gmail.com>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
When encountering a PTR query, `connlib` checks if the query is for a
Firezone-managed resource and resolve it to the correct IP. If it isn't
for a DNS resource, we should forward the query to the upstream
resolver.
This isn't what is currently happening though. Instead of forwarding the
query, we bail early from `StubResolver::handle` and thus attempt to
route the packet through the tunnel. This however fails because the DNS
query was targeted at `connlib`'s stub resolver address which never
corresponds to a resource IP.
When TRACE logs where activated, this resulted in several entries such
as
> Unknown resource dst=100.100.111.1
To ensure this doesn't regress, we now generate PTR and MX record
queries in `tunnel_test`. We don't assert the response of those but we
do assert that we always get a response. The inclusion of MX records
asserts that unknown query types get correctly forwarded.
Resolves: #6749.
There were 3 problems currently on main, one on the tests and the actual
bug.
## Test problem
The routes were kept in a `BTreeSet` that when a new route was added it
was `insert`ed into and when it was removed it was `remove`d from using
the address of the route.
The problem is if there were overlapping route added twice in a row and
then a single one of those resources is removed the test would believe
the route no longer exists.
## Test solution
Keep the routes in a `BTreeMap` which maps the id to the ip and then we
calculate the routes based on that combined with the default routes,
that way we just remove the ID and the routes are kept in the correct
expected state.
## Real bug
So fixing this revealed a similar bug in connlib, since we kept things
in a similar struct, `active_cidr_resources` using `IpNetworkTable`.
To fix this I re-calculate the whole table each time we add/remove a
resource.
Note that this really doesn't properly fixes overlapping routes, this is
just helpful to fix the test, to fix them we need #4789
Furthermore, fixing these issues revealed an additional problem,
whenever we add an overlapping CIDR resource the old resource might be
overridden, causing the connection to be lost, furthermore this happened
in a non-deterministic(it's deterministic really but not explicit) way
causing the tests to fail.
To fix this we always sort resources by ID(it's an arbitrary order to
keep consistency with the proptests) and then we don't replace the
routing for resources that already had a connection.
Sadly, to model this in the test I had to almost copy exactly how we
calculate resources in connlib.
Fixes#6721
---------
Signed-off-by: Gabi <gabrielalejandro7@gmail.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
This patch adds a notification for updates for macos clients when they
are on an old version.
This is how it looks:
<img width="497" alt="image"
src="https://github.com/user-attachments/assets/829044fd-e8bc-4b47-b64d-67b8ef72adb0">
The orange dot is shown regardless of the notification being dismissed.
If the notification is dismissed by the "Dismiss this version" button,
until there's no new version there won't be notifications.
Updates are check at the start of firezone and every 6 hours after. This
is saved in `UserDefaults`.
Permissions for notifications needs to be allowed so that it's show,
this should be done by the `requestAuthorization`
Also, when an update is available a new `Update available...` option
appears in the menu
<img width="230" alt="image"
src="https://github.com/user-attachments/assets/16d7fea8-3cf5-4711-9d42-5c49faffe6c8">
This option, same as the notification takes you to the appstore.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Refs #6547, this fixes a similar error message but it's not the same
exact issue.
When IPv6 is disabled on a system, our call to set the MTU was failing
with error code 0x80070490. This patch allows some of the MTU-related
syscalls to fail with a warning log.
To replicate the issue, run this command to set a registry value to
disable IPv6, then reboot the system:
`reg add
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters"
/v DisabledComponents /t REG_DWORD /d 255 /f`
```[tasklist]
- [x] Update changelog
- [x] Apply PR feedback
```
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
