fix(udpgw): move magic IP out of tun2proxy virtual-DNS range#1143
Merged
therealaleph merged 1 commit intoMay 13, 2026
Merged
Conversation
therealaleph
pushed a commit
that referenced
this pull request
May 13, 2026
Closes #1145. LibreWolf users were getting `MOZILLA_PKIX_ERROR_MITM_DETECTED` when visiting HSTS-protected sites (bing.com, youtube.com, …) through MasterHttpRelayVPN's MITM mode. HSTS gives no "Add Exception" affordance, so users were fully locked out of those sites despite the OS-level CA install having succeeded. **Root cause**: `cert_installer.rs` only scanned Firefox profile roots (`~/.mozilla/firefox`, the snap variant, `%APPDATA%\Mozilla\Firefox\Profiles`, `~/Library/Application Support/Firefox/Profiles`). LibreWolf is a Firefox fork with strict privacy defaults; it shares Firefox's NSS DB layout and respects the same `security.enterprise_roots.enabled` pref, but stores its profile tree under its own app dir. Neither the per-profile `certutil -A` install nor the `user.js` enterprise-roots auto-trust fallback ever touched LibreWolf, so the browser never trusted our CA. Same failure mode behind already-closed #955 and #959 (Firefox-fork users reporting the identical "secure connection could not be established" symptom). **Fix**: extend Mozilla-family profile discovery to cover LibreWolf on every supported platform. No behavioural change for Firefox installs. ## Changes (`src/cert_installer.rs`-only) - Renamed `firefox_profile_dirs()` → `mozilla_family_profile_dirs()`. Same flat-vec return type so all five call sites read identically; the rename is signposting only. - Extracted `mozilla_family_profile_roots(os, home, appdata, xdg_config_home)`: returns the union of Firefox + LibreWolf profile root directories, per-OS: - **Linux**: `~/.mozilla/firefox`, snap variant, `~/.librewolf`, `$XDG_CONFIG_HOME/librewolf` (LibreWolf respects XDG by default). - **macOS**: `~/Library/Application Support/Firefox/Profiles`, `~/Library/Application Support/LibreWolf/Profiles`. - **Windows**: `%APPDATA%\Mozilla\Firefox\Profiles`, `%APPDATA%\LibreWolf\Profiles`. - All five existing call sites (per-profile install, enterprise-roots fallback, uninstall, dry-run reporter, test-mode reporter) read from the renamed function without further changes. ## Verified locally (on top of v1.9.24) - `cargo test --lib --release`: **239/239** ✅ (was 231; this PR adds 8 new tests covering LibreWolf-path discovery on each OS). - `cargo build --release --features ui --bin mhrv-rs-ui`: clean ✅ ## Will combine with #1143 PR #1143 already pre-baked the v1.9.25 release files (Cargo.toml + changelog). This PR doesn't touch either, so the squash-merge will land cleanly alongside #1143's changes. Will edit v1.9.25's changelog to include #1159 as a second bullet before tagging. Reviewed via Anthropic Claude. Co-Authored-By: dazzling-no-more <noreply@github.com> Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
therealaleph
added a commit
that referenced
this pull request
May 13, 2026
…all (#251, #1145) v1.9.25 ships two bug fixes from @dazzling-no-more: - #1143 (#251): Android Full-mode `udpgw magic IP` moved from 198.18.0.1 → 192.0.2.1 to avoid clash with tun2proxy's virtual-DNS allocator range. Resolves "Google + most websites silently broken while Telegram works" on Android Full mode. Back-compat: legacy IP still recognised by tunnel-node for one deprecation cycle. - #1159 (#1145): MITM CA now installs into LibreWolf NSS stores alongside Firefox. Closes `MOZILLA_PKIX_ERROR_MITM_DETECTED` HSTS lockout on LibreWolf. Same class as already-closed #955/#959. Cargo.toml bump (1.9.24 → 1.9.25) came in via #1143. This commit amends the pre-baked v1.9.25 changelog to include #1159 and refreshes Cargo.lock. 239 lib tests + 38 tunnel-node tests pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #251.
Summary
In Android Full mode, Telegram worked but Google search and most other websites failed silently.
apps_scriptmode on the same setup was unaffected and the VPS was idle.Root cause: the udpgw magic destination (
198.18.0.1:7300) was inside198.18.0.0/15— the exact range that tun2proxy's--dns virtualallocator uses to synthesise fake IPs for hostname lookups. Whenever virtual DNS assigned198.18.0.1to a real hostname, that hostname's traffic was intercepted by tun2proxy itself as a udpgw connection and dropped. Telegram was immune because it uses hardcoded numeric IPs;apps_scriptmode was immune because it never sets--udpgw-server.Fix: move
UDPGW_MAGIC_IPto192.0.2.1(RFC 5737 TEST-NET-1) — outside any virtual-DNS allocation pool. Coordinated change across the tunnel-node constant and the Android--udpgw-serverflag.Back-compat
v1.9.25 tunnel-nodes still recognise the legacy
198.18.0.1:7300for one deprecation cycle (removal in v1.10.0).198.18.0.1, so the #251 virtual-DNS collision is still live on-device192.0.2.1)The fix lives on the client side (which magic IP it asks tun2proxy to reserve). The back-compat shim only prevents a hard handshake break during the version-skew window. Recommended upgrade: APK first, or both halves together.
Version bumps
Cargo.toml:1.9.24→1.9.25.android/app/build.gradle.kts:versionName1.8.1→1.9.25,versionCode158→159. The Android version name had been stale since v1.8.1 across every v1.9.x release — closing the gap here so Difference between app-script mode and full-tunnel mode #251 diagnostics can identify which APK build a stuck user is on.