Don't take our word for it

Start a packet capture first, so nothing slips past: run Wireshark (or another capture tool) on your network interface with no filter, and keep it running. Before you start, clear your computer's DNS cache, so names the app looks up show as fresh queries instead of being answered from the cache:

Windows:

ipconfig /flushdns

Linux (systems that use systemd-resolved; elsewhere there's usually no local cache to clear):

resolvectl flush-caches

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Close other apps first (browsers, chat, sync tools) and note when you start and stop, so their traffic doesn't get pinned on SubnetSlinger. Then open the app, leave it idle for a few minutes, and use a few tools. When you stop the capture, Wireshark's Statistics ▸ Endpoints (IPv4 and IPv6 tabs) lists every address your computer talked to, including a license check that's over in under a second. Check the addresses as well as the names: some traffic never makes a DNS query (the gateway ping and addresses you typed as numbers). With DNS-over-HTTPS on, the name you look up travels inside HTTPS: you'll see one ordinary query for cloudflare-dns.com, then encrypted traffic.

A capture shows addresses, not which program made them. To tie every connection, however short, to SubnetSlinger, use one of these:

• Windows: Sysinternals TCPView keeps closed connections on screen for a moment, labeled by process. Or turn on connection auditing (admin PowerShell or Command Prompt) and read Event Viewer ▸ Windows Logs ▸ Security, event 5156, filtered on SubnetSlinger.App.exe. Turn it back off when you're done.

auditpol /set /subcategory:"Filtering Platform Connection" /success:enable

Use the app, read event 5156, then turn auditing back off:

auditpol /set /subcategory:"Filtering Platform Connection" /success:disable

• Linux: trace the app's network calls (the app's process ID comes from pgrep -f SubnetSlinger; add -f to follow the programs it starts):

sudo strace -f -e trace=network -p "$(pgrep -of SubnetSlinger)"

• macOS: nettop lists live connections by process (we haven't run this on a Mac ourselves yet):

nettop -p SubnetSlinger

For a quick look at the app's own connections, these show what's open at that moment. They're a snapshot, so a short connection can slip between two runs.

Windows (PowerShell, with the app running):

$p = (Get-Process SubnetSlinger* -ErrorAction SilentlyContinue).Id
if (-not $p) { 'SubnetSlinger is not running' } else {
  Get-NetTCPConnection -OwningProcess $p -ErrorAction SilentlyContinue | Select-Object OwningProcess, RemoteAddress, RemotePort, State
  Get-NetUDPEndpoint -OwningProcess $p -ErrorAction SilentlyContinue | Select-Object OwningProcess, LocalAddress, LocalPort
}

No output while the app is idle is normal: it has nothing open.

Or open Resource Monitor (resmon), go to the Network tab and check the box next to the SubnetSlinger process.

Linux:

ss -tunp | grep -i subnetslinger

macOS:

lsof +c 0 -i -n -P | grep -i subnetslinger

We haven't run this macOS command on a Mac ourselves yet. If it prints nothing while the app is clearly connected, please tell us.

Some tools hand the work to your operating system. On Linux, pings (including Home's gateway ping) run the system ping program; the CLI wrappers run tools such as nmap, curl and tracert or traceroute; iperf3 runs as its own process; and MCP servers you add run as their own processes. On Linux every ping-based tool (Ping, Traceroute, Path ping, Path MTU and Home's gateway check) runs the system ping program. On Windows, pings go through the operating system itself, so they don't show under any app. The DNS lookup tool asks your DNS server directly, so its queries do show under SubnetSlinger; names you type into other tools are resolved by the operating system. The Console's SSH runs inside the app. The packet capture catches all of it either way.

What you should see while idle: on Windows and Linux, a ping to your own default gateway each time Home opens (that's Home answering "is my network up?", and it stays on your LAN; the Mac app asks the system's network monitor instead, see the macOS section), and, if you're signed in, the short license check in the cases the Privacy page lists. Everything else appears only after you open a screen that needs it or press a button.

Incoming, too: the Windows Store install adds inbound firewall allow rules for the app, on Private networks only, for the local servers (syslog, SNMP traps, TFTP, DNS, DHCP, RADIUS, TACACS+, FTP, HTTP and their high-port fallbacks). Nothing listens until you start a Local server, a Lab Testing listener or an iperf3 server (iperf3 runs as its own process). To check (PowerShell):

$p = (Get-Process SubnetSlinger* -ErrorAction SilentlyContinue).Id
if (-not $p) { 'SubnetSlinger is not running' } else {
  Get-NetTCPConnection -State Listen -OwningProcess $p -ErrorAction SilentlyContinue | Select-Object LocalAddress, LocalPort
  Get-NetUDPEndpoint -OwningProcess $p -ErrorAction SilentlyContinue | Select-Object LocalAddress, LocalPort
}

No output means nothing is listening. A short-lived UDP row while you run a DNS lookup is the lookup itself, not a listener.

One exception you create yourself: if you press Add firewall rules on the Local servers screen, Windows adds inbound rules for the same ports in a group named SubnetSlinger. Those rules are open to any program on Private networks, not just SubnetSlinger, and they stay after you uninstall the app. The Store install doesn't need them. To remove them, open Windows Defender Firewall ▸ Inbound Rules and delete the SubnetSlinger group, or run this in an admin PowerShell:

Remove-NetFirewallRule -Group 'SubnetSlinger'

Every host the app can contact is on the Trust page firewall allowlist, with what each one is for and when it's used. The Privacy page says exactly what each one is sent. That list is for Windows and Linux; the Mac app uses a few different lookup services, listed in the macOS section of the Privacy page. Some tools come pre-filled with example public targets (DNS lookup uses cloudflare.com, Ping and Traceroute use google.com when there's no gateway, Path MTU uses 1.1.1.1 and the Field Kit falls back to 8.8.8.8), so you'll see those when you run them with the defaults. Anything else you see that isn't on the list for your platform is a bug; please tell us.

Connections to your own devices (the switch you ping, the server you SSH to) are the tools doing their job, and only happen when you run them.

Cut the internet but keep your LAN: the simplest way is to disconnect your router's internet uplink (WAN). Per-app firewall rules are hard to get right for this test (on Windows a block rule beats an allow rule, and pings go out through the operating system rather than the app), so we don't recommend them. The free tools keep working with no account and no internet. Pro needs a check-in every 30 days and a trial every 14; on Windows and Linux, opening the Account screen does it. So a Pro license keeps working up to 30 days offline after its last check-in, while a trial has no offline grace. Tools that exist to reach the internet (speed test, WHOIS, public IP, a cloud AI) say they can't reach it; nothing else breaks.

• No AI in use: if you never open the Deputy or the Posse, no AI host appears in step 1. Opening the Deputy screen with a cloud provider selected (Anthropic is the default) fetches our public model and price list, subnetslinger.com/models.json, and, if you've added a key, asks that provider for its model list. No question or network data is sent until you ask one.
• Local AI: choose Ollama on this machine; the only AI traffic is to localhost:11434.
• Cloud AI: your questions go only to the provider you picked, with your key. You'll also see the model-list fetches above.
• Spend cap: in the Deputy's Setup, type 0.01 into Cap per Posse run (don't spin it down to 0.00, which turns the cap off) and start a cloud Posse run; it refuses before sending anything. (This needs Pro or a trial and a cloud AI key; without a key the run stops earlier, for that reason. Afterward, set Cap per Posse run back to 2.00.) The daily cap works differently: it stops new questions once today's spend reaches it, so the first question of the day can still go out. A cap of 0 turns that cap off.

Windows installs come from the Microsoft Store, which signs them. macOS builds are notarized by Apple. For Linux and macOS, check the GPG signature and the SHA-256 checksum before installing; the steps and our key's fingerprint are on the Setup page. The component list (SBOM) sits beside each Linux and macOS download, so your scanner can check what's inside.

Everything the app keeps is in folders on your machine: settings, inventory, incidents and the Vault in the app's data folder, and exports, captures and reports in a SubnetSlinger folder in your Documents. In the app, File ▸ Open exports folder and the Show log file button on the Activity screen take you straight there. On Linux 1.3.0 the Show log file button doesn't open the folder, so use the paths below.

• Linux: ~/.config/SubnetSlinger and ~/Documents/SubnetSlinger
• Windows (Store app): the app's folder under %LOCALAPPDATA%\Packages (the app itself shows it as %APPDATA%\SubnetSlinger), plus Documents\SubnetSlinger
• macOS: ~/Library/Application Support/SubnetSlinger; Vault secrets stay in the Mac's Keychain

On Windows and Linux, view the Vault file, vault.json, in a text viewer (don't save it from an editor, which can damage it). The saved passwords are encrypted (AES-256-GCM), not readable text. The Activity log records what the app did and when, so you can match it against step 1.

If anything doesn't match what we say, that's a bug we want to fix. Email sheriff@subnetslinger.com or see Report a vulnerability. Known problems, and how to fix or work around them, are in our security advisories.