Chapter 10 of 12
Network Tools, Zero Trust, Import & Appearance
The remaining features: local test servers for validating network gear, an IP scanner, a dedicated Zero Trust broker-tunnel panel, Wake-on-LAN, importing sessions from other tools, and the theme system.
Local Test Servers (HTTP, iPerf3, RADIUS)
Purpose
Spin up a throwaway HTTP file server, an iPerf3 bandwidth-test server, or a real RADIUS AAA server directly from MangoSSH — for validating network gear/firewall rules/switch AAA config without standing up FreeRADIUS or a separate web server.
How to do it
- Open More → Servers .
- HTTP : pick a Document root folder and Port (8080 default), click Start .
- iPerf3 : pick a Port (5201 default), click Start , then point a real iPerf3 client at this machine.
- RADIUS : pick a Port (1812 default) and Shared secret , add one or more Test users (username/password), click Start .
- Supports both plain PAP and full PEAPv0/EAP-MSCHAPv2 (real 802.1X-style enterprise Wi-Fi testing, deriving real MPPE keying material, not just an Access-Accept), auto-detected by whether the incoming request carries an EAP-Message attribute.
How to verify
- HTTP: browse to http:// < this-machine > :8080 from another device and confirm the document root's files list.
- iPerf3: run iperf3 -c < this-machine > from another device and confirm a real throughput result.
- RADIUS (PAP): point a switch/AP's AAA config at this server and secret, and confirm a test user's login succeeds with an Access-Accept.
- RADIUS (PEAP/802.1X): configure an enterprise or guest Wi-Fi SSID to use this server, and confirm the full 802.1X handshake and the WPA2/3 4-way handshake both complete — not just a RADIUS-level accept, since that's the actual proof MPPE keys came through correctly.
Troubleshooting
- RADIUS client gets no response at all — confirm the shared secret matches exactly on both sides and that UDP 1812 (or whatever port you set) isn't blocked by a local firewall.
- RADIUS accepts the login but the Wi-Fi 4-way handshake fails — this points at the PEAP/MPPE path specifically rather than basic auth; confirm the AP/controller is actually configured for PEAPv0/EAP-MSCHAPv2, not a different EAP method entirely.
IP Scanner
Purpose
Quickly find which hosts in a range are alive and have a given TCP port open — before adding them as saved connections, or while mapping an unfamiliar network.
How to do it
- Open More → IP Scan .
- Enter a Range (CIDR like 192.168.1.0/24 , or a hyphenated range like 192.168.1.1-254 ), a TCP port to probe (22 for SSH, 80 for web, 445 for SMB, etc.), and a per-host Timeout .
- Click " n Scan" .
- Results stream in live as a row per responding host — only hosts that actually answer appear; unresponsive addresses are simply never listed, there is no per-row "closed"/"refused" status.
How to verify
- Scan a range containing a host you know is up with that port open.
- Expect a row for it reading < port > open , the progress bar to show "done / total (pct%)" while scanning, and the summary above the results to read "N alive" as hits stream in.
- Let the scan finish.
- Expect the progress bar to read "Done — N scanned in Xs" and the summary to settle on "N alive / M scanned" , and the Scan button to re-enable.
- Scan the same range for a port you know is closed on every host in it.
- Expect the result list to stay empty (or show only hosts that respond to plain ping if no port narrows it down) — not rows labeled "Refused" or "Closed", since only responding hosts are ever listed at all.
Troubleshooting
- Nothing appears for a host you know is up — raise the Timeout value on a slow/flaky network before concluding it's down; a too-aggressive timeout drops real, reachable hosts silently rather than reporting them as "closed".
Zero Trust Broker Tunnels (Dedicated Panel)
Purpose
- Set up and test a cloud-broker tunnel (AWS SSM, GCP IAP, Azure Bastion, Cloudflare Access, Teleport, Tailscale SSH) in its own panel — including a live cluster/node browser for Teleport — then push the working command straight into a saved SSH host's Delegate tab.
- This is the setup/test workbench for the same brokers the SSH chapter's ProxyCommand quick-presets cover — use whichever entry point is more convenient; both end up configuring the same field.
How to do it
- Open More → Zero Trust and pick a broker tab (AWS, GCP, Azure Bastion, Cloudflare, Teleport, or Tailscale).
- Fill in that broker's specific fields (e.g. AWS Instance ID + Region, or Teleport's Proxy host + a live Cluster/Node picker).
- Click Test to verify the tunnel actually works, then Use in SSH host to copy the resulting command into the Delegate tab of a new or existing SSH host.
How to verify
- Fill in a broker's fields with real values (e.g. a real AWS Instance ID + Region, or a Teleport Proxy host with a cluster/node picked from the live picker) and click Test .
- Expect a clear success indicator before you rely on it inside a saved host — this catches a broker-login/permission problem early, separately from any SSH-auth troubleshooting.
- Click " → Use in SSH host" .
- Expect it to open (or jump to) an SSH host's Delegate tab with the resulting ProxyCommand already filled in, matching what the SSH chapter's ProxyCommand quick-presets would have produced for the same broker.
- Deliberately break one field (e.g. a wrong AWS Region or Teleport Proxy host) and click Test again.
- Expect a clear failure indicator rather than a false success.
Troubleshooting
- Test fails — this isolates the problem to the broker CLI/login itself (see the SSH chapter's ProxyCommand troubleshooting) before you've even touched a saved host.
Wake-on-LAN
Purpose
Power on a machine remotely that's configured to listen for a WoL magic packet — useful for waking a server before connecting to it.
How to do it
- Open More → Wake-ON-LAN .
- Enter the target's MAC Address and, if needed, a specific Broadcast Address (leave blank for the default).
- Click Send Magic Packet .
How to verify
- Enter the correct MAC address for a machine you know has Wake-on-LAN enabled and is currently powered off, leave Broadcast Address blank, and click "Send Magic Packet" .
- Expect the machine to power on within a few seconds.
- Send the same packet again while the machine is already on.
- Expect no error and no adverse effect — sending a magic packet to an already-running machine is a harmless no-op, not something that needs guarding against.
- Deliberately mistype one octet of the MAC address and send again.
- Expect the target machine to stay off — confirming the packet actually is MAC-specific and not just broadcasting a generic wake-everything signal.
Troubleshooting
- Nothing happens — WoL must be enabled in that machine's BIOS/UEFI and its OS network adapter settings; also confirm the broadcast address actually reaches that machine's subnet (a magic packet sent to the wrong broadcast address/VLAN never arrives).
Importing Sessions from Other Tools
Purpose
Bring an existing connection list in from OpenSSH's own config file, PuTTY, or MobaXterm, instead of re-typing every saved host by hand.
How to do it
- Toolbar → More → Import sessions… .
- Pick a provider: OpenSSH (reads ~/.ssh/config ), PuTTY (reads its saved sessions from the registry on Windows, or its config files on macOS/Linux), or MobaXterm (reads MobaXterm.ini — auto-detected, or point at a specific path).
- Review the scanned list (one checkbox row per discovered session) and confirm which ones to bring in.
How to verify
Import from a tool with a known session list and confirm the count and host/port/username values match the source exactly for a few spot-checked entries.
Troubleshooting
- Provider finds zero sessions — confirm the source tool's config actually exists at the expected location; for MobaXterm specifically, try pointing directly at its .ini file rather than relying on auto-detect.
Appearance — UI Mode & Themes
Purpose
Match MangoSSH's look to your preference or environment — a dense "Classic" mode vs. a more spacious "Modern" layout, and any of 14 built-in themes (including two glass-style themes, Nebula Glass and Daylight Glass — the default), plus a full custom theme editor.
How to do it
- Open Settings → Appearance.
- Pick a UI mode (Modern/Classic) and a Theme from the swatch grid.
- For a fully custom look, open the Theme editor to override individual colors; its " n Reset" button clears your overrides back to the selected theme's own defaults.
How to verify
- Switch themes from the swatch grid and confirm every open view (not just Settings itself) picks up the new colors immediately, with no leftover styling from the previous theme.
- Open the Theme editor, change the accent color, and click Apply .
- Confirm the new color shows up across the app immediately.
- Click " n Reset" in the Theme editor.
- Confirm your custom override is cleared and the app returns to the selected theme's original color, not a blank/unstyled state.
Troubleshooting
- Custom theme looks broken somewhere — use the Theme editor's " n Reset" button rather than trying to manually restore every color back to a known-good state.