fwknop Single Packet Authorization for Hidden Firewall Services

Why fwknop Conceals SSH and Internal Services

fwknop addresses the exposure created when a firewall leaves a service such as SSH reachable to every address that can find its port. Its intended users are firewall administrators, operators of gateway systems, and remote users who need controlled access without publishing a normal inbound service port. The documented deployment keeps SSH or another protected service behind a default-drop filtering policy, while the fwknop daemon temporarily changes firewall rules after it accepts a valid Single Packet Authorization request. The client does not open a listening port and does not send a multi-packet sequence. It sends one packet that contains the authorization data required to request access. According to the README, a concealed service cannot be scanned with Nmap because it has no open port. This changes the security objective from making a port hard to guess to removing it from ordinary network discovery. SPA does not replace the service's own authentication, vulnerability patching, or firewall policy. It controls whether the firewall permits traffic to reach the service. The project documentation presents this as a way to make exploitation of unpatched or previously unknown service vulnerabilities more difficult, but that claim depends on the firewall rule remaining closed until an authorized packet is processed.

The fwknop Packet Flow and Firewall Backends

The client creates an SPA packet, and the server-side daemon obtains that packet passively, usually through libpcap or another packet-acquisition method. The daemon validates the packet, applies authorization rules, and changes the relevant firewall rule. A client request can therefore open access to a service such as SSH for a defined period or request access through a NAT gateway. The README identifies support for iptables, firewalld, PF, and ipfw across Linux, OpenBSD, FreeBSD, and Mac OS X. It also documents custom scripts, which can connect fwknop to infrastructure such as ipset or nftables. That script route is an integration boundary rather than a guarantee that every firewall implementation is built in. The daemon must already be running, have access to incoming packets, and be configured to communicate with the firewall. This makes deployment more involved than simply sending an application request. A packet can be valid and still be rejected because the service is not enabled, the source address is not authorized, the requested access is outside the configured policy, or the daemon cannot apply the requested rule. The project also handles replay detection through digest comparison, with SHA-256 described as the default.

HMAC, Rijndael, and GnuPG Packet Protection

fwknop supports HMAC authenticated encryption using an encrypt-then-authenticate design. The README says HMAC support is currently optional through the command line switch `--use-hmac`, but it strongly recommends enabling it. The documented rationale is specific. Without an HMAC, cryptographically strong authentication is unavailable unless GnuPG is used, and the HMAC also protects against CBC-mode padding-oracle classes of attacks. The daemon checks the HMAC before sending SPA data through decryption routines, including when GnuPG is used. fwknop supports Rijndael for symmetric encryption and GnuPG for asymmetric encryption and decryption. With Rijndael, the shared encryption key is configured for the client and server, and the project documentation states that PBKDF1 derives the actual key while CBC mode is used. With GnuPG, keys come from GnuPG key rings. HMAC uses a separate key, so administrators need to manage both the encryption material and the HMAC key. The README points to `/etc/fwknop/access.conf` for symmetric-key configuration and states that keys can be generated with `--key-gen`. This is a substantial operational detail. Misconfigured keys, incorrect firewall addresses, or inconsistent client and server settings can prevent requests from being accepted even when the service and daemon are running.

Installation and First Access Through the Project Tutorial

The repository includes `INSTALL`, `Makefile.am`, `autogen.sh`, `configure.ac`, platform directories, and a detailed tutorial link, but the README excerpt does not provide a complete installation command sequence or a verified first-use invocation. It points readers to the project tutorial for the full procedure. Because the exact package dependencies, configure flags, service installation commands, and platform-specific daemon startup steps are not documented in the README excerpt, this review does not invent them. The first practical task is therefore to follow the linked tutorial for the target operating system and firewall backend, then configure the client and server with matching access rules and keys. The README identifies `/etc/fwknop/access.conf` as the place associated with symmetric-key details. It also documents `--use-hmac` and `--key-gen`, but it does not present a complete command that can safely be copied as a first client request. The documented client platforms are Linux, Mac OS X, *BSD, and Windows under Cygwin. An Android client is separately available. Before attempting access, verify that the firewall is in the intended default-drop state, the daemon is configured for the correct interface, and the protected service has a rule that the daemon can temporarily enable.

When fwknop Is the Wrong Firewall Choice

fwknop is not a general replacement for host firewalls, VPN software, service authentication, or network access management. It requires a compatible firewall backend and a deployment capable of receiving and interpreting packets before traffic reaches the protected service. Organizations that cannot change firewall rules dynamically, cannot run the daemon with sufficient packet visibility, or cannot distribute and protect client keys should not assume that SPA will improve their security. The project also requires administrators to reason about NAT. The README specifically highlights NAT support for iptables and firewalld, including access to internal services through a gateway, but that benefit depends on correct placement and configuration at the firewall. A rule that opens the wrong interface, port, address, or direction can produce confusing results. The project is more involved than a simple port-knocking sequence because it combines encryption, HMAC validation, replay handling, authorization, and firewall changes. GnuPG adds key-ring and asymmetric-key dependencies. The GUI client is documented as supporting major SPA modes, NAT requests, HMAC and Rijndael keys, and saved `fwknoprc` stanzas, while GnuPG is not yet supported there. That difference matters for client selection.

Maintenance, Release Cadence, and License Obligations

The repository is not archived, and its last push was on 2026-06-01. The README identifies version 2.6.11 as the latest documented release, dated 2024-02-07. Those facts indicate repository activity after that release, but the README does not provide a release schedule, compatibility statement for newer operating systems, or a detailed upgrade procedure. Maintenance cost therefore includes checking whether the selected firewall backend, packet capture method, and client platform remain compatible with the installed version. The project is primarily written in Perl, while the repository also includes `client/`, `server/`, `common/`, `lib/`, and platform-specific directories such as `android/`, `iphone/`, and `win32/`. The repository is licensed under GPL-2.0. Anyone distributing a modified or integrated copy should review the license obligations that apply to that distribution. This review does not provide legal advice. The separate GUI and Android clients are named as external or separately hosted projects, so their update cycles and licensing cannot be inferred from this repository's GPL-2.0 declaration.

Comparing fwknop With Conventional Port Knocking

Port knocking asks a client to send a predetermined sequence of packets before a firewall opens a port. fwknop retains the general idea of hiding a service behind a closed firewall, but replaces the sequence with a single SPA packet. The README identifies replay resistance, asymmetric cipher support, and HMAC support as practical differences. A conventional knock sequence can be disrupted by injecting an extra packet, according to the project description. SPA combines encrypted and authenticated packet data, performs replay detection through digests, and can use GnuPG or Rijndael. The cost is a more complex configuration model. Port knocking may be simpler to explain when a static sequence and a simple firewall rule are sufficient. fwknop becomes relevant when the protected service is behind NAT, when cryptographic authentication is required, or when an administrator wants to avoid exposing the service port to normal scanning. The comparison is not absolute. fwknop still depends on firewall correctness, secret key protection, packet delivery, and daemon availability. It changes how access is requested, not whether the underlying firewall or service is secure.

Editorial conclusion

Adopt fwknop when an administrator needs temporary, packet-triggered access to services behind a default-drop firewall, especially through NAT. Do not choose it without checking firewall integration, key distribution, HMAC configuration, and the platform-specific daemon setup. The last push was on 2026-06-01, and the documented latest release is 2.6.11 from 2024-02-07.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. mrash/fwknop on GitHub
3. Project website
4. README
5. Releases