Right now, whenever a connection is established we update the site
status.
In order to do that, we call `on_update_resources`, when
`on_update_resources` is called this in turn calls
`set_disabled_resources`, since we apply from the application side the
"disabled" given the current resources.
`set_disabled_resources` currently, always call `on_update_routes`,
which causes connectivity issues on Android and MacOS, since the packets
aren't correctly routed when the routes are changed.
To fix this we make `set_disabled_resources` only emit the routes when
they have actually changed.
Fixes: #6387.
---------
Signed-off-by: Gabi <gabrielalejandro7@gmail.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
- Consistent link/button font size on landing
- Use new elevator graphic and remove redundant HTML/CSS
- Removes underline on some ActionLinks because the color is not applied
correctly (Tailwind bug?)
This library wasn't being actively maintained which caused a
compatibility issue with newer versions of the `mixpanel-browser`
library.
This PR also updates other dependencies via `pnpm update`.
Currently, `connlib` can only handle "simple" DNS wildcards where `*`
matches any number of subdomains, including zero and `?` matches a
single subdomain.
With this PR, we expand `connlib'`s capabilities to allow for a much
more complex matching of domains that more closely resembles glob
patterns:
- `**` matches any number of subdomains. This supersedes the previous
`*` operator.
- `*` matches a single subdomain. This supersedes the previous `?`
operator.
- `?` matches a single character. This wasn't possible before.
- Additionally, any of these can be combined. Previously, only `*` or
`?` was allowed and they were only accepted at the front of the domain
name pattern.
Resolves: #5056.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Fixes#6155
One question we get with almost each new customer is "if I enable sync,
won't that count towards my bill?". This PR aims to answer that question
right when they create the provider.
I will also make sure to update Enterprise accounts in Stripe with
`monthly_active_users_acount` so that they can view this metric on the
Billing page.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Closes#5453
Tested once on the Windows aarch64 VM. Should always leave 4 files
behind, a `.log` and a `.jsonl` for the GUI and for the IPC service. The
"log directory" is a bit of a lie since it's consistently 2 directories
on both platforms now.
```[tasklist]
- [x] Update changelog
- [x] Make a note to remove the known issue from the website when the next release is cut after this PR merges
```
For efficiency reasons, TURN's data channels don't have any
authentication or integrity metadata. Instead, the operate using a short
2-byte channel number to identify the target peer of the data.
To avoid abuse, channel bindings are at most valid for 10 minutes before
they need to be refreshed. In case they expire, there is a 5 minute
cooldown period, before the same channel number can be bound to a
different peer and before the same peer can be bound to a different
channel.
We had a similar issue in the past (#5613) where channels got rebound
early. Whilst that was fixed and is no longer happening, a case that we
didn't consider is what happens if we want to bind a channel to a peer
that still has a channel bound but is currently cooling down (i.e. in
the 5 minute period after its expiry).
In that case, `snownet` would wrongly assume that there is no channel to
this peer and try to bind a new one. That would get rejected by the
relay with a bad request.
To fix this, we simply need to check whether we still have a channel to
this peer and if yes, return the same channel number. On the relay, we
need to ensure that we consider a channel as `bound` again when it is
being refreshed.
We ensure that this doesn't regress in two ways:
- We add a unit-test for the `ChannelBindings` struct
- We modify the `Idle` transition to idle for 6 instead of 5 minutes.
This ensures that a combination of 2 idle transitions puts the channel
bindings into the 10-15 minute time window where rebinding the peer to a
different channel fails.
Related: #6265.
If a new resource is created that will use format not supported by
previous client versions we temporarily show a warning:
<img width="683" alt="Screenshot 2024-08-07 at 2 28 57 PM"
src="https://github.com/user-attachments/assets/bbfdfc96-0c4b-4226-93c5-bc2b5fdb9d30">
It will also be excluded from `resources` list for older clients (below
1.2).
---------
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
When forwarding DNS queries, we need to remember the original source
socket in order to send the response back. Previously, this mapping was
indexed by the DNS query ID. As it turns out, at least Windows doesn't
have a global DNS query ID counter and may reuse them across different
DNS servers. If that happens and two of these queries overlap, then we
match the wrong responses together.
In the best case, this produces bad DNS results on the client. In the
worst case, those queries were for DNS servers with different IP
versions in which case we triggered a panic in connlib further down the
stack where we created the IP packet for the response.
To fix this, we first and foremost remove the explicit `panic!` from the
`make::` functions in `ip-packet`. Originally, these functions were only
used in tests but we started to use them in production code too and
unfortunately forgot about this panic. By introducing a `Result`, all
call-sites are made aware that this can fail.
Second, we fix the actual indexing into the data structure for forwarded
DNS queries to also include the DNS server's socket. This ensures we
don't treat the DNS query IDs as globally unique.
Third, we replace the panicking path in
`try_handle_forwarded_dns_response` with a log statement, meaning if the
above assumption turns out wrong for some reason, we still don't panic
and simply don't handle the packet.
Without masquerading, packets sent by the gateway through the TUN
interface use the wrong source address (the TUN device's address)
instead of the gateway's actual network interface.
We set this env variable in all our uses of the gateway, thus we might
as well remove it and always perform unconditionally.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
It's missing a couple pieces, see the tasklist
Refs #5123
```[tasklist]
- [x] Add `Add to Favorites` and `Remove from Favorites` buttons
- [x] Update Changelog
- [x] Load and save Favorites from `SharedPreferences`
- [x] Wire up `onClick` events
- [x] Hide and show Resources in the menu based on whether they're favorited
- [x] Hide tabs if nothing is favorited
- [x] Tab icons
- [ ] Make the "Reset Settings" button also reset Favorites
- [ ] Change the "Add to Favorites" and "Remove from Favorites" to a checkbox or star or something cool
```
Closes#5063, supersedes #5850
Other refactors and changes made as part of this:
- Adds the ability to disable DNS control on Windows
- Removes the spooky-action-at-a-distance `from_env` functions that used
to be buried in `tunnel`
- `FIREZONE_DNS_CONTROL` is now a regular `clap` argument again
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
