Zedmos

8. Troubleshooting

⌘K

Symptoms, in the order a support engineer would work through them. The principle underneath all of them: find the first place the truth differs from what you expect, and stop guessing there.

The method

  1. What changed? System → Configuration → History records every change and who made it. Most faults are twenty minutes old.
  2. Does the appliance itself work? Dashboard — services running, gateway up, disk not full.
  3. Where does the traffic stop? Firewall → Log Files → Live View shows what arrives and what is done with it. If a packet is not there, it never reached the appliance.
  4. What did the service say? Every service has a log page, and the status page next to it usually answers the question in one line.

No internet from the LAN

The appliance reaches the internet; clients do not.

  • Does the client have an address? Services → Kea DHCP → Leases DHCPv4. No lease means DHCP, not routing: is the server on for that interface, is the range inside the subnet, is there a second DHCP server on the segment?
  • Is its gateway the appliance? Check on the client itself.
  • Can it resolve names? If names fail but addresses work, it is DNS: check Services → Unbound DNS → General (is the resolver answering on that interface, and is its access list allowing that network?).
  • Is a rule blocking it? Firewall → Log Files → Live View, filtered to the client's address. A new interface starts with nothing allowed — a fresh VLAN with no rules behaves exactly like a broken network.
  • Is the traffic being translated? Firewall → NAT → Source NAT: a network the appliance does not translate leaves with a private source address and nothing comes back.

A port forward does not work

Work outwards, in this order:

  1. Firewall → Log Files → Live View — does the packet arrive on the WAN? If not, the problem is upstream: your provider, a modem in router mode, or another firewall in front.
  2. Does it show as blocked? Then the firewall rule that accompanies the forward is missing, disabled, or below a blocking rule.
  3. Does it show as passed and the client still gets nothing? The internal server is not listening, or has its own firewall.
  4. Are you testing from inside? A client on the LAN reaching the WAN address takes a different path. Test from outside.

A VPN will not come up

WireGuard — VPN → WireGuard → Status:

  • No handshake: the two ends are not reaching each other. Check the WAN rule for the listen port, and the endpoint address on the initiating side.
  • Handshake but no traffic: routing or rules. Allowed IPs must cover the networks in both directions, and the tunnel interface needs rules.

IPsec — VPN → IPsec → Log File, read from the bottom. The last message before it gives up names the mismatch: proposals (encryption and DH group) or traffic selectors, and both ends must agree exactly.

OpenVPN — VPN → OpenVPN → Connection Status and its log. A client that connects and is immediately dropped is usually a certificate problem — expired, revoked, or issued by a different authority.

Locked out of the panel

  • Wrong address? The console's System status prints the panel's address.
  • Wrong port or interface? System → Settings → Administration can move the panel; the console shows where it ended up.
  • Password not accepted? Console menu, Reset the root password — it sets the console, SSH and web password together.
  • A rule you just wrote? The appliance notices when a change has locked out its administrator and rolls that change back on its own. If it has not, use the console: Reload all services, or System → Configuration → History to go back a step once you are in.
  • Nothing works and the box is remote? That is what the console menu and a configuration backup are for. Factory reset is the last resort, and it erases everything.

A service will not start

  1. System → Diagnostics → Services — is it enabled and what state is it in?
  2. Its own Log File page — the reason is almost always in the last few lines.
  3. System → Log Files → Boot — if it fails at boot, this is the ordered account of why.

Two recurring causes: a port already in use (two services configured to answer DNS on the same interface, for instance), and a missing certificate (a VPN server pointed at a certificate that was deleted).

The appliance is slow

  • System → Diagnostics → Activity — what is using the CPU.
  • Firewall → Diagnostics → Statistics — states in use against the limit. Approaching the limit explains connections that fail under load.
  • Dashboard → Resources — memory and disk. A full disk makes everything strange.
  • With the security engine: inspection costs CPU. Security and Policy → Live Sessions shows what is being inspected, and an exclusion for bulk traffic (backups, video) often recovers more than any tuning.

Time is wrong

Services → Network Time → Status shows whether a server is actually selected and what the offset is. A wrong clock breaks certificate validation, VPN negotiation and every timestamp you will later rely on — fix it before investigating anything that depends on it.

What to send to support

  • The version — System → Firmware → Status.
  • The package list — System → Firmware → Packages.
  • The relevant log page, downloaded as text.
  • What you expected, what happened, and when it last worked.
  • A configuration backup only if asked, and over a channel you trust: it contains every secret the appliance holds.
Previous7. Maintenance