4e11112d9b
Turns out the multi-threaded access of the TUN device on the Gateway causes packet reordering which makes the TCP congestion controller throttle the connection. Additionally, the default TX queue length of a TUN device on Linux is only 500 packets. With just a single thread and an increased TX queue length, we get a throughput performance of just over 1 GBit/s for a 20ms link between Client and Gateway with basically no packet drops: ``` Connecting to host 172.20.0.110, port 5201 [ 5] local 100.79.130.70 port 49546 connected to 172.20.0.110 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 116 MBytes 977 Mbits/sec 0 6.40 MBytes [ 5] 1.00-2.00 sec 137 MBytes 1.15 Gbits/sec 0 6.40 MBytes [ 5] 2.00-3.00 sec 134 MBytes 1.13 Gbits/sec 0 6.40 MBytes [ 5] 3.00-4.00 sec 136 MBytes 1.14 Gbits/sec 47 6.40 MBytes [ 5] 4.00-5.00 sec 137 MBytes 1.15 Gbits/sec 0 6.40 MBytes [ 5] 5.00-6.00 sec 138 MBytes 1.16 Gbits/sec 0 6.40 MBytes [ 5] 6.00-7.00 sec 138 MBytes 1.15 Gbits/sec 0 6.40 MBytes [ 5] 7.00-8.00 sec 138 MBytes 1.15 Gbits/sec 0 6.40 MBytes [ 5] 8.00-9.00 sec 138 MBytes 1.16 Gbits/sec 0 6.40 MBytes [ 5] 9.00-10.00 sec 138 MBytes 1.15 Gbits/sec 0 6.40 MBytes [ 5] 10.00-11.00 sec 139 MBytes 1.17 Gbits/sec 0 6.40 MBytes [ 5] 11.00-12.00 sec 139 MBytes 1.17 Gbits/sec 0 6.40 MBytes [ 5] 12.00-13.00 sec 136 MBytes 1.14 Gbits/sec 0 6.40 MBytes [ 5] 13.00-14.00 sec 139 MBytes 1.17 Gbits/sec 0 6.40 MBytes [ 5] 14.00-15.00 sec 140 MBytes 1.17 Gbits/sec 0 6.40 MBytes [ 5] 15.00-16.00 sec 138 MBytes 1.16 Gbits/sec 0 6.40 MBytes [ 5] 16.00-17.00 sec 137 MBytes 1.15 Gbits/sec 0 6.40 MBytes [ 5] 17.00-18.00 sec 139 MBytes 1.17 Gbits/sec 0 6.40 MBytes [ 5] 18.00-19.00 sec 138 MBytes 1.16 Gbits/sec 0 6.40 MBytes [ 5] 19.00-20.00 sec 136 MBytes 1.14 Gbits/sec 0 6.40 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-20.00 sec 2.67 GBytes 1.15 Gbits/sec 47 sender [ 5] 0.00-20.02 sec 2.67 GBytes 1.15 Gbits/sec receiver iperf Done. ``` For further debugging in the future, we are now recording the send and receive queue depths of both the TUN device and the UDP sockets. Neither of those showed to be full in my testing which leads me to conclude that it isn't any buffer inside Firezone that is too small here. Related: #7452 --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
gui-client
This crate houses a GUI client for Linux and Windows.
Setup (Ubuntu)
To compile natively for x86_64 Linux:
- Install rustup
- Install pnpm
sudo apt-get install build-essential curl file libayatana-appindicator3-dev librsvg2-dev libssl-dev libwebkit2gtk-4.1-dev libxdo-dev wget
Setup (Windows)
To compile natively for x86_64 Windows:
- Install rustup
- Install pnpm
Recommended IDE Setup
(From Tauri's default README)
Building
Builds are best started from the frontend tool pnpm. This ensures typescript
and css is compiled properly before bundling the application.
See the package.json script for more details as to what's
going on under the hood.
# Builds a release exe
pnpm build
# Linux:
# The release exe and deb package are up in the workspace.
stat ../target/release/firezone
stat ../target/release/bundle/deb/*.deb
# Windows:
# The release exe and MSI installer should be up in the workspace.
# The exe can run without being installed
stat ../target/release/Firezone.exe
stat ../target/release/bundle/msi/Firezone_0.0.0_x64_en-US.msi
Signing the Windows MSI in GitHub CI
The MSI is signed in GitHub CI using the firezone/firezone repository's
secrets. This was originally set up using these guides for inspiration:
- https://melatonin.dev/blog/how-to-code-sign-windows-installers-with-an-ev-cert-on-github-actions/
- https://support.globalsign.com/code-signing/code-signing-using-azure-key-vault
Renewing / issuing a new code signing certificate and associated Azure entities is outside the scope of this section. Use the guides above if this needs to be done.
Instead, you'll most likely simply need to rotate the Azure CodeSigning Application's client secret.
To do so, login to the Azure portal using your @firezoneprod.onmicrosoft.com account.
Try to access it via the following deep-link.
If that doesn't work:
- Go to the
Microsoft Entra IDservice - Click on
App Registrations - Make sure the tab
All applicationsis selected - Find and navigate to the
CodeSigningapp registration - Client on
client credentials - Click
New client secret - Note down the secret value. This should be entered into the GitHub repository's secrets as
AZURE_CLIENT_SECRET.
Running
From this dir:
# This will start the frontend tools in watch mode and then run `tauri dev`
pnpm dev
# You can call debug subcommands on the exe from this directory too
# e.g. this is equivalent to `cargo run -- debug hostname`
cargo tauri dev -- -- debug hostname
# The exe is up in the workspace
stat ../target/debug/Firezone.exe
The app's config and logs will be stored at
C:\Users\$USER\AppData\Local\dev.firezone.client.
Platform support
Ubuntu 22.04 and newer is supported.
Tauri says it should work on Windows 10, Version 1803 and up. Older versions may work if you manually install WebView2
x86_64 architecture is supported for Windows. aarch64 and x86_64 are supported for Linux.
Threat model
See Security