Feature Request: Include Source IP in “Non‑corresponding HMAC” Log Messages for Better Integration with Log‑Based Security Tools

[sergioprg]

Hello fwknop developers,

I’d like to propose a small enhancement to the fwknopd logging output that would greatly improve integration with downstream security tools such as Fail2Ban, log processors, SIEMs, etc.

Current behavior
When fwknopd receives a Single‑Packet Authorization (SPA) packet, it always logs a line like:

(stanza #N) SPA Packet from IP: 1.2.3.4 received with access source match

in all cases, followed—on HMAC failure—by:

(stanza #N) Non-corresponding HMAC for this stanza

Unfortunately, the HMAC‑failure message does not include the source IP, forcing users to correlate two separate lines in the log stream (the SPA receipt and the HMAC failure) in order to identify which IP actually failed authentication. This correlation can easily break under load or in a DoS scenario when multiple IPs send SPA packets at once.

Use case: Fail2Ban and other log‑based ban tools
I run fwknop behind a public-facing service and rely on Fail2Ban to automatically ban IP addresses that repeatedly send invalid SPA packets. Fail2Ban works by scanning log lines for an IP token (via ), but because the HMAC‑failure line lacks an IP, it either:

Counts every SPA (valid or not) as a failure and risks banning legitimate clients when their SPA succeeds.

Ignores HMAC failures and fails to ban malicious actors at all.

Neither option is ideal. If the HMAC‑failure message itself contained the IP—e.g.:

(stanza #N) Non-corresponding HMAC for stanza N from IP: 1.2.3.4

—then tools like Fail2Ban could unambiguously extract and ban exactly those IPs that failed the HMAC check, without false positives or race conditions.

Benefits of adding the IP to HMAC‑failure logs
Accurate banning: downstream scripts and services can ban only truly invalid clients.

Simpler automation: no need for fragile multi‑line or regex workarounds to stitch together two separate log entries.

Better audit trails: full context in each line makes it easier to reconstruct an incident in a SIEM or during forensic analysis.

Community use: many third‑party tools expect an IP in the error message; this change would improve compatibility across the board.

Proposed change
In server/incoming_spa.c, the call:

LOG_WARNING("Non-corresponding HMAC for this stanza");

could be modified to include the source IP, for example:

char ip_str[INET6_ADDRSTRLEN];
inet_ntop(AF_INET, &pkt_data->src_addr.sin_addr, ip_str, sizeof(ip_str));
LOG_WARNING("Non-corresponding HMAC for stanza %d from IP %s", stanza_index, ip_str);

This small change would preserve all existing functionality while giving users the ability to parameterize and ban based on that single log line.

Thank you for considering this enhancement! It would make fwknop even more powerful in real‑world deployments that rely on real‑time log analysis and automated response.

Best regards,

Sergio