Kerio VPN client on Linux: five checks in order
Five checks in order: package architecture, the CLI wizard, the config file, the service script and the logs. Stop at the first one that fails.
No desktop icon appears after you install the Kerio VPN client on Linux, and the private network stays out of reach. That is the normal shape of this client rather than a broken install: GFI's Linux instructions describe command-line configuration and a service script, with no GUI at all. Work the checks below in order, because each one clears a different layer. The first failure tells you where to stop, and skipping ahead usually means rebuilding a package that was never the problem.
Confirm the build matches the machine
Start with what dpkg thinks the machine is and what the package was built for. On a normal 64-bit system, dpkg --print-architecture prints amd64, and the vendor page lists an amd64 package next to the ordinary Debian one. Read the release string in the filename you actually installed instead of assuming the two agree.
A 2013-era archive built for i386 does not become 64-bit because you passed --force-architecture. Forcing it installs foreign binaries, hides a dependency failure behind a launcher that still starts, and can leave the daemon loading the wrong libraries. If the release you have only ships 32-bit, run it in a 32-bit environment or ask the gateway owner for a current build.
Check the dependency line as well. dpkg -s kerio-control-vpnclient | grep -i depends shows what the package expects, and an unmet version pin or missing runtime library surfaces here rather than in the client log.
Configure it through the package wizard
The client has no application-drawer entry by design, so a missing icon says nothing about whether configuration succeeded. Reopen the wizard with sudo dpkg-reconfigure kerio-control-vpnclient and answer its prompts: VPN endpoint, account details, and the server certificate fingerprint.
Treat the fingerprint prompt as the one place a wrong server can win. Compare the value against the server information from the administrator who runs the gateway, not against whatever the endpoint presents. Accepting a fingerprint you cannot verify turns the rest of this checklist into decoration, because a hostile server looks identical to the real one once the pin is stored. If the value cannot be confirmed out of band, stop and ask, even when the tunnel would otherwise come up.
Re-running the wizard changes configuration and can restart the client, so keep a second path onto the machine when the session you are working over depends on that VPN. Type the password at the normal prompt instead of embedding it in a command that lands in shell history.
Know the file the wizard writes
Configuration lives in /etc/kerio-kvc.conf, and it carries both the account and the pinned fingerprint. Treat it as secret material. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf should not show it as world-readable.
After an authorised manual edit, reload the daemon that owns the file rather than restarting the network stack: sudo /etc/init.d/kerio-kvc reload. A reload re-reads the configuration and drops the current session, so it is not a no-op on a live connection.
Copy the previous file before you change anything. If authentication fails after an edit, restoring the last known-good copy takes seconds and isolates the edit from the network, which is the cheapest way to learn which one moved.
Separate the live session from boot behaviour
The service script controls the current connection: sudo /etc/init.d/kerio-kvc stop ends the tunnel now and start brings it back. Neither command decides what happens at the next boot, and that difference matters on a machine you administer remotely.
Inspect who owns startup before removing links or masking anything. The package may install its own init script, generate a unit, or do both, and disabling the wrong name leaves the client back after a reboot. Check systemctl status kerio-kvc against the name the package documentation uses, then disable the path the boot process actually reads.
Do not substitute an OpenVPN unit because the configuration looks similar. This client speaks its own protocol to the Kerio gateway, so another daemon pointed at the same file will not authenticate, and the extra failure makes the evidence harder to read. GFI's Linux client also holds one VPN connection at a time; that limit applies to the client, not to the gateway's user capacity.
Read the logs, then verify the resource
Three files under /var/log/kerio-kvc carry the daemon's story: init.log for lifecycle events, error.log for critical failures, and debug.log for detail. Read the smallest excerpt that answers your question, and remove endpoints and usernames before pasting it anywhere. A gap in init.log around the time you ran the wizard tells you the daemon never restarted.
| File | Read it for | Skip it when |
|---|---|---|
init.log | start, reload and stop events | you already know the daemon restarted |
error.log | failed authentication and certificate problems | the tunnel is up and traffic still fails |
debug.log | protocol detail worth attaching to a ticket | the error is already named in error.log |
A valid package, a running daemon, and a reachable resource are three separate results, and the checklist is finished only when all three hold. After an approved change, request a host that exists only behind the gateway, then open a normal service on it. If the tunnel is up and the resource is not, the remaining fault sits in a gateway route or firewall rule rather than in the client you just reconfigured.
Record the state you ended in: package release, architecture, whether the fingerprint was verified out of band, and which reload or restart you ran. That note is what makes the next person's first check cheap.