We reserve an IP range _within_ the CG-NAT range for the sentinel DNS
servers. It is unnecessary to explicitly add that one as a route because
it is already covered by the routing entry of the entire CG-NAT range.
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>
Merging #6708 had an unintended side-effect that we are seeing a lot of
WARN logs from phoenix-channel because we can no longer parse the
response from gateways. We didn't do anything with these responses but
gateways are sending them for backwards-compatibility reasons.
To not confuse ourselves while debugging, we revert the client-side bit
of #6708 to remove these warnings.
Now you can "edit" any fields on the policy, when one of fields that
govern the access is changed (resource, actor group or conditions) a new
policy will be created and an old one is deleted. This will be
broadcasted to the clients right away to minimize downtime. New policy
will have it's own flows to prevent confusion while auditing. To make
experience better for external systems we added `persistent_id` that
will be the same across all versions of a given policy.
Resources work in a similar fashion but when they are replaced we will
also replace all corresponding policies.
An additional nice effect of this approach is that we also got
configuration audit log for resources and policies.
Fixes#2504
This adds a feature that will email all admins in a Firezone Account
when sync errors occur with their Identity Provider.
In order to avoid spamming admins with sync error emails, the error
emails are only sent once every 24 hours. One exception to that is when
there is a successful sync the `sync_error_emailed_at` field is reset,
which means in theory if an identity provider was flip flopping between
successful and unsuccessful syncs the admins would be emailed more than
once in a 24 hours period.
### Sample Email Message
<img width="589" alt="idp-sync-error-message"
src="https://github.com/user-attachments/assets/d7128c7c-c10d-4d02-8283-059e2f1f5db5">
Currently, checking whether a packet is a DNS query has multiple silent
exit paths. This makes it DNS problems difficult to debug because the
packets will be treated as if they have to get routed through the
tunnel.
This is also something we should fix but that isn't done in this PR: If
we know that a packet is for connlib's DNS stub resolver, we should
never route it through the tunnel. Currently, this isn't possible to
express with the type signature of our DNS module and requires more
refactoring.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
DNS queries for non-resources get forwarded by connlib byte-for-byte and
only the IP & UDP headers gets rewritten. The responses for some DNS
queries don't fit into UDP packets. To signal this, DNS servers set the
TC (truncated) bit on the response.
If set, most clients will discard the response and requery over TCP. DNS
over TCP is not yet supported in connlib, meaning any query response
that has the TC bit set will most likely lead to DNS issues downstream.
To make these cases easier to debug, we log a warning whenever we
encounter a DNS response from an upstream server that that has the TC
bit set.
Prior to version 1.1.0, clients did not have an embedded DNS resolver
and relied on the gateway for DNS resolution. In that design, the
gateway responded with the IPs that the domain resolved to.
Our next iteration of the control protocol (#6461) will decouple the
details of how DNS works from the flow-authorization. As a result, we
will need to be able to establish a flow for a DNS resource without
knowing which concrete domain the client is going to access.
Without a concrete domain, we cannot send anything back to these old
clients, meaning we unfortunately have to break compatibility with <
1.1.0 clients as part of implementing the new control protocol.
This only happens once for each domain, so logging this on DEBUG should
be fine. It is disabled by default and shouldn't be too spammy during
development.
This happens because the smoke test is stubbed out for release builds,
so any `use` statements that are only used in the smoke tests will cause
a warning in `--release` builds, including when we make release bundles.
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>
The `expect` attribute is similar to `allow` in that it will silence a
particular lint. In addition to `allow` however, `expect` will fail as
soon as the lint is no longer emitted. This ensures we don't end up with
stale `allow` attributes in our codebase. Additionally, it provides a
way of adding a `reason` to document, why the lint is being suppressed.
Instead of forcing NIx users of the respository (me) to install RA
globally, we can install the equivalent version of whatever Rust version
we depend on.
Bumps androidx.test:runner from 1.6.1 to 1.6.2.
[](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
[@fontsource/source-sans-3](https://github.com/fontsource/font-files/tree/HEAD/fonts/google/source-sans-3)
from 5.0.20 to 5.1.0.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/fontsource/font-files/commits/HEAD/fonts/google/source-sans-3">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 the com-android group in /kotlin/android with 1 update:
com.android.application.
Updates `com.android.application` from 8.5.1 to 8.6.0
[](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
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [flowbite](https://github.com/themesberg/flowbite) from 2.4.1 to
2.5.1.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/themesberg/flowbite/releases">flowbite's
releases</a>.</em></p>
<blockquote>
<h2>v2.5.1</h2>
<ul>
<li>fix plugin import error from the config file</li>
</ul>
<h2>v2.5.0</h2>
<ul>
<li>added new DataTable plugin and examples</li>
<li>minor bug fixes and improvements</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="362ad079dc"><code>362ad07</code></a>
chore(version): update to <code>v2.5.1</code></li>
<li><a
href="b30fd48555"><code>b30fd48</code></a>
fix(plugin): remove import</li>
<li><a
href="878ced1b62"><code>878ced1</code></a>
docs(datatables): add to readme</li>
<li><a
href="09105b8429"><code>09105b8</code></a>
chore(version): bump to <code>2.5.0</code></li>
<li><a
href="70411d572a"><code>70411d5</code></a>
docs(datatables): add docs for js init, options, and methods</li>
<li><a
href="fc26a5e4c9"><code>fc26a5e</code></a>
feat(datatables): finish coding the dropdowns for exporting</li>
<li><a
href="bab0a3317f"><code>bab0a33</code></a>
feat(datatables): inject export dropdown button inside table header</li>
<li><a
href="f842793de9"><code>f842793</code></a>
feat(datatables): add basic export files feature</li>
<li><a
href="e56f601069"><code>e56f601</code></a>
docs(datatables): finish row selection example and docs</li>
<li><a
href="ba771d4738"><code>ba771d4</code></a>
feat(datatables): add row selection example</li>
<li>Additional commits viewable in <a
href="https://github.com/themesberg/flowbite/compare/v2.4.1...v2.5.1">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>
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>
On Windows, the network notifier always notifies once at startup. We
make the DNS notifier and Linux match this behavior, and we assert it in
the unit test.
Part of a yak shave towards removing Tauri.
In #6592, we started tracking our connected gateways to correctly model,
which packets get dropped as part of establishing new connections. We
forgot to clear this when connections are being reset, causing some test
failures.
The CAA can't be set for a domain that has a CNAME record, see
https://letsencrypt.org/docs/caa/
> Note also that CAA checking follows CNAME redirects, just like all
other DNS requests. If
“[community.example.org](http://community.example.org/)” is a CNAME to
“[example.forum.com](http://example.forum.com/)”, the CA will respect
any CAA records that are set on
“[example.forum.com](http://example.forum.com/)”. It is not allowed for
a domain name with a CNAME record to have any other records, so there
cannot be conflicts between CAA records on the original name and CAA
records on the target of the redirect.
