Download Aircast

VPN & Browser Conflicts

Use this guide when the AirCast device is online but the dashboard won't open in one browser or from one laptop. Before re-flashing anything: if a second browser, SSH, or your ground station still reaches the device, the device is fine — something on the operator side is intercepting the traffic.

Typical symptoms

  • Edge opens the dashboard, but Chrome shows 504 Gateway Time-out or ERR_CONNECTION_TIMED_OUT for the same address.
  • QGroundControl telemetry and SSH work over Tailscale, but the browser dashboard doesn't.
  • ping and curl reach the device, but one browser profile fails.
  • The dashboard loads but the WebRTC video stays black — the VPN passes TCP but blocks the UDP that video rides on.
  • The dashboard fails only while a desktop or router VPN is enabled.

Fast field fix

  1. Disable browser VPN/proxy extensions. Open chrome://extensions and switch off VPN extensions (Urban VPN and similar), privacy proxies, and ad blockers with proxy features. These affect only that browser — everything else on the laptop keeps working, which is exactly why they're easy to miss.
  2. Test a clean profile. If Incognito (with extensions disabled) opens the dashboard, the normal profile is at fault: clear the site's data for the device address, then flush caches at chrome://net-internals/#dns and #sockets, and reload with Ctrl+Shift+R.
  3. Disable desktop VPN clients — or add split-tunnel exclusions for the ranges AirCast lives on:
    • 100.64.0.0/10 — Tailscale addresses (the 100.x.x.x device IPs)
    • 192.168.0.0/16 and 172.16.0.0/12 — normal LAN ranges
    • 192.168.100.0/24 — the Starlink dish address, if you use one

Prove whether the device or the browser is at fault

From Windows PowerShell (replace the address with your device's LAN or Tailscale IP):

Test-NetConnection 100.x.x.x -Port 80
curl.exe -sS -D - --max-time 8 http://100.x.x.x/ -o NUL

If the TCP test succeeds and curl gets an HTTP response, the device and the network path are healthy — fix the browser profile, extension list, or VPN policy. If both fail from every tool, it's a real connectivity problem: check the device's uplink and Tailscale status on its local network first.

Desktop VPN clients and Windows proxies

Corporate agents, WireGuard/OpenVPN clients, and commercial VPN apps can install routes that capture private ranges, or outright block LAN access while the tunnel is up. Check for routes and proxy state:

route print
netsh winhttp show proxy

Look for:

  • Routes for 100.64.0.0/10 or 192.168.0.0/16 going through the VPN adapter.
  • VPN options named Block LAN, Kill switch, Secure all traffic, or Force tunnel — any of these will break local and Tailscale access.
  • A system proxy under Windows Settings → Network & Internet → Proxy.

Router-side VPNs and guest networks

A WiFi router running its own VPN client can break access even when the laptop has no VPN at all. The usual culprits:

  • Route all clients through VPN modes that capture Tailscale's 100.64.0.0/10 traffic.
  • Guest WiFi / client isolation — blocks laptop-to-device LAN traffic entirely. Put the laptop and the AirCast device on the same trusted network.
  • Firewall rules that block UDP — the dashboard (TCP) works but WebRTC video and telemetry forwarding don't.