nftables Logging and Rate Limiting: Complete Guide 2026

Posted on October 2, 2026 By corginetwork Leave a comment Cybersecurity

nftables Logging and Rate Limiting: Complete Guide to Logs, Counters, Limits, and NFLOG

When an nftables firewall drops a packet, knowing that the connection failed is not enough.

A network administrator needs to answer much more useful questions:

Which rule matched the packet? Why was it dropped? Was the connection NEW or INVALID? How many packets are hitting the rule? Is the traffic legitimate, misconfigured, or potentially hostile?

This is where nftables logging and rate limiting become essential.

nftables provides several complementary mechanisms for firewall visibility: the log statement can record matching traffic, counter can track packets and bytes, limit can prevent excessive logging or control matching rates, and NFLOG can send selected firewall events to userspace logging systems.

A properly designed firewall therefore becomes more than:

Packet
   ↓
ACCEPT / DROP

It becomes:

Packet
   ↓
Conntrack State
   ↓
Firewall Rule
   ↓
Counter
   ↓
Selective Logging
   ↓
Rate Control
   ↓
ACCEPT / DROP

That distinction is crucial in production networks.

The official nftables logging documentation documents the log statement and Netfilter logging capabilities, while the official nftables rate-limiting documentation explains how limit can control rule matching rates.

This guide shows how to combine these features into a practical Linux firewall monitoring and troubleshooting strategy.

If you are not yet comfortable with NEW, ESTABLISHED, RELATED, and INVALID, first read our nftables Conntrack States and Troubleshooting guide because connection state is fundamental to useful firewall logging.

 

What Is nftables Logging and Rate Limiting?

nftables logging records information about packets that match firewall rules, while nftables rate limiting controls how frequently selected traffic can match a rule.

They are frequently combined because unrestricted firewall logging can generate enormous amounts of data.

For example:

log prefix "NFT_DROP: " drop

can record packets before dropping them.

But on an Internet-facing firewall receiving thousands of unwanted packets per second, logging every dropped packet could produce:

thousands of events
        ↓
large system logs
        ↓
high disk I/O
        ↓
CPU overhead
        ↓
important events buried in noise

A better design combines:

counter
+
rate-limited logging
+
drop policy

This gives administrators visibility without unnecessarily logging every packet.

Why nftables Logging Matters

Consider this firewall:

table inet firewall {

    chain forward {
        type filter hook forward priority filter;
        policy drop;

        ct state established,related accept

        ip saddr 192.168.10.0/24 \
        ip daddr 192.168.20.10 \
        tcp dport 443 \
        accept
    }
}

The security policy is straightforward:

ESTABLISHED / RELATED
        ↓
ACCEPT

LAN → Web Server TCP/443
        ↓
ACCEPT

Everything else
        ↓
DROP

Now imagine a client cannot connect to the web server.

The user reports:

Connection timed out

Without additional visibility, several completely different problems could produce that symptom:

wrong route
wrong interface
firewall drop
incorrect destination
INVALID conntrack state
server firewall
application not listening
asymmetric routing

Logging is one tool for identifying which layer is responsible.

However, it should be combined with counters, connection tracking, packet capture, and tracing rather than treated as the only diagnostic tool.

nftables Logging vs Counters

One of the most important distinctions for firewall administrators is:

Feature Primary Question
counter How many packets and bytes matched?
log What traffic matched?
limit How frequently should this rule match?
Conntrack What connection does this packet belong to?
tcpdump Did the packet appear on this interface/path?
nft monitor trace How did nftables process this packet?

These tools complement each other.

For example:

tcp dport 443 counter accept

may show that the rule has matched thousands of packets.

That can prove the firewall rule is active without generating thousands of log entries.

The official nftables Counters documentation explains both anonymous counters attached to rules and named counter objects.

How to Log Packets with nftables

The basic syntax uses the log statement.

For example:

tcp dport 22 log accept

This means:

TCP destination port 22
        ↓
LOG
        ↓
ACCEPT

Logging does not itself determine the final firewall verdict.

You can use:

log accept

or:

log drop

depending on the policy.

This is an important conceptual separation:

Logging observes traffic; the firewall verdict decides what happens to it.

How to Log Dropped Packets with nftables

A basic drop-logging rule could look like:

log prefix "NFT_DROP: " drop

A forwarding chain might therefore contain:

chain forward {

    type filter hook forward priority filter;
    policy drop;

    ct state established,related accept

    ip saddr 192.168.10.0/24 \
    ip daddr 192.168.20.10 \
    tcp dport 443 \
    accept

    log prefix "NFT_FORWARD_DROP: " drop
}

The packet path becomes:

Packet
   ↓
ESTABLISHED / RELATED?
   ├── YES → ACCEPT
   ↓
Permitted new connection?
   ├── YES → ACCEPT
   ↓
LOG
   ↓
DROP

This immediately gives you more visibility than an unexplained default drop.

However, this rule can become dangerous on a busy firewall because every matching packet can generate logging activity.

Why You Should Not Log Every Dropped Packet

Suppose an Internet-facing interface receives:

5 dropped packets/second

Logging may be manageable.

Now suppose a scanner, misconfigured system, or traffic spike produces:

20,000 dropped packets/second

Unrestricted logging can produce significant:

log volume
disk writes
CPU usage
journal growth
storage consumption
monitoring noise

More logging does not necessarily mean better observability.

A useful firewall should prioritize high-signal events.

This leads to one of the most important production nftables techniques:

Rate-Limited Logging

Instead of logging every matching packet, apply a rate limit.

For example:

limit rate 5/second log prefix "NFT_DROP: "

This allows the logging rule to match at a controlled rate.

The nftables project’s rate-limiting documentation describes the limit statement and its use for controlling matching rates.

But there is an important trap here.

Rate-Limit the Logs, Not Accidentally the Security Policy

Suppose your intention is:

LOG only a small sample
DROP every prohibited packet

That is not the same as:

DROP only packets that pass the rate limiter

A clearer pattern separates the logging action from the drop action.

For example:

ct state invalid \
limit rate 5/second \
log prefix "NFT_INVALID: " \
counter

ct state invalid counter drop

The logic becomes:

INVALID packet
      ↓
Within logging rate?
   ├── YES → LOG
   └── NO  → skip logging
      ↓
DROP

Every matching INVALID packet can still be dropped by the second rule.

Only selected packets generate log entries.

This separation is particularly useful on production firewalls.

Understanding limit rate in nftables

A simple rate limiter might be:

limit rate 5/second

or:

limit rate 10/minute

The appropriate value depends on the purpose of the rule.

There is no universal correct setting.

For example, diagnostic logging for an Internet-facing firewall may require a different rate from logging administrative SSH attempts.

Think in terms of:

What event am I measuring?
        ↓
How often should it normally occur?
        ↓
How much logging is operationally useful?

rather than copying a limit from another firewall.

nftables Burst Rate Limiting

Network traffic frequently arrives in bursts rather than at a perfectly uniform rate.

Conceptually:

Second 1 → 1 packet
Second 2 → 3 packets
Second 3 → 40 packets
Second 4 → 2 packets

The nftables limit mechanism can accommodate bursts, allowing short spikes while still restricting sustained matching.

This can be useful for:

SSH connection attempts
ICMP
firewall logging
administrative services
unexpected connection attempts

The important principle is that burst allowance and sustained rate are different dimensions.

A short burst does not necessarily indicate abuse.

Logging INVALID Conntrack Traffic

One of the best places to combine connection tracking and rate-limited logging is:

ct state invalid

For example:

ct state invalid \
limit rate 5/second \
log prefix "NFT_CT_INVALID: " \
counter

ct state invalid counter drop

This gives you evidence about packets that Netfilter cannot associate with valid connection state as expected.

Unexpected INVALID traffic may be associated with:

asymmetric routing
expired connection state
unexpected packet sequences
malformed packets
unusual network behavior

It should not automatically be interpreted as malicious.

Our nftables Conntrack States and Troubleshooting guide explains why INVALID is a diagnostic state rather than a simple synonym for “attack.”

Logging NEW Connections

Logging every packet in an established connection usually provides little value.

Often, the interesting event is the creation of the connection.

Suppose a management network is allowed to SSH to a server:

Management VLAN
192.168.30.0/24
        ↓
TCP/22
        ↓
Server
192.168.20.10

You might log new SSH connections:

ip saddr 192.168.30.0/24 \
ip daddr 192.168.20.10 \
tcp dport 22 \
ct state new \
limit rate 10/minute \
log prefix "NFT_ADMIN_SSH_NEW: "

and then apply the corresponding accept policy.

This records:

NEW SSH connection

instead of every packet exchanged during the SSH session.

That is usually far more useful.

Should You Log ESTABLISHED Traffic?

Usually not packet by packet.

A rule such as:

ct state established,related log accept

could produce enormous amounts of logging because established flows may contain thousands or millions of packets.

For normal stateful firewall operation, this is usually preferable:

ct state established,related counter accept

You retain traffic statistics without creating a log entry for every packet.

If you need connection-level visibility, log strategically around new or security-relevant events instead.

Logging Accepted Traffic

Dropped traffic is not the only traffic worth monitoring.

You may want to log selected successful connections such as:

administrator SSH sessions
VPN establishment
access to sensitive infrastructure
new connections to protected services
temporary troubleshooting traffic

For example:

ip saddr 192.168.30.0/24 \
ip daddr 192.168.20.10 \
tcp dport 22 \
ct state new \
log prefix "NFT_ADMIN_SSH: " \
counter \
accept

But do this because the event has operational or security value.

Do not turn every successful packet into a log entry.

Use Descriptive nftables Log Prefixes

Consider:

log

versus:

log prefix "NFT_DMZ_LAN_DENIED: "

The second is far more useful.

A good naming strategy might include:

NFT_WAN_INPUT_DROP:

NFT_FORWARD_DROP:

NFT_CT_INVALID:

NFT_ADMIN_SSH_NEW:

NFT_LAN_DMZ_DENIED:

NFT_DMZ_LAN_DENIED:

NFT_DNAT_NEW:

You can then search for a particular event.

For example:

journalctl -k | grep NFT_CT_INVALID

or:

journalctl -k | grep NFT_DMZ_LAN_DENIED

depending on your distribution and logging configuration.

Good prefixes turn logs into structured operational clues.

Avoid Meaningless Prefixes

Avoid:

DROP1
DROP2
RULE7
TEST
BLOCK

Six months later, these labels provide almost no context.

Prefer a naming convention based on:

firewall
+
zone
+
direction
+
reason

For example:

NFT_WAN_INPUT_DROP
NFT_DMZ_LAN_DENIED
NFT_LAN_SSH_DENIED
NFT_FORWARD_INVALID

This becomes increasingly valuable as the ruleset grows.

nftables Counters: Often the First Tool You Should Use

Before enabling packet logging, ask:

Do I simply need to know whether the rule is matching?

If yes, use a counter.

For example:

ip saddr 192.168.10.0/24 \
ip daddr 192.168.20.10 \
tcp dport 443 \
counter \
accept

Then inspect:

sudo nft list chain inet firewall forward

You may see packet and byte statistics for that rule.

This answers:

Does HTTPS traffic reach this firewall rule?

without creating thousands of log entries.

Use Counters to Follow the Packet

Counters become especially powerful when placed at multiple stages.

Consider DNAT:

Internet
   ↓
PREROUTING
   ↓
DNAT
   ↓
FORWARD
   ↓
DMZ Server

Suppose you observe:

DNAT counter:
2,105 packets

FORWARD HTTPS counter:
2,105 packets

Return traffic counter:
0 packets

This strongly changes the investigation.

You already know that:

traffic reached DNAT
        +
traffic passed FORWARD

The next questions concern:

server
application
server firewall
return route

rather than the initial DNAT rule.

This methodology is covered in detail in nftables DNAT Port Forwarding Not Working.

Anonymous vs Named nftables Counters

A simple counter is embedded directly into a rule:

tcp dport 443 counter accept

This is an anonymous counter.

nftables can also use named stateful counter objects.

Conceptually:

counter web_https
counter blocked_wan
counter invalid_forward

Named counters can make statistics easier to organize in larger rulesets.

The official nftables Counters documentation explains both approaches.

For a small firewall, anonymous counters are often sufficient.

For a large structured firewall, named counters may improve monitoring and readability.

Counters Are Not Logs

A counter showing:

packets 25000
bytes 19000000

does not tell you:

which IP generated the traffic
when the packets arrived
which individual connection was involved

Counters answer:

How much?

Logs help answer:

What?
Who?
When?

This is why the best monitoring strategy uses the correct tool for each question.

Reading nftables Logs with journalctl

On systemd-based Linux distributions, firewall messages routed through the kernel logging path may be inspected using:

journalctl -k

If you use descriptive prefixes:

journalctl -k | grep NFT_

can quickly isolate firewall-related messages.

Or:

journalctl -k | grep NFT_INVALID

can narrow the investigation to a specific class of events.

The exact logging path depends on the Linux distribution and logging configuration, so do not assume every system stores firewall messages identically.

What Is NFLOG in nftables?

For more advanced logging architectures, nftables can send matching packet information to a Netfilter logging group.

This enables NFLOG, where userspace software can consume firewall events.

Conceptually:

Packet
   ↓
nftables
   ↓
NFLOG group
   ↓
Userspace logging
   ↓
Storage / Analysis

This differs from relying solely on ordinary kernel logging.

The official nftables logging documentation documents logging groups and the NFLOG mechanism.

When Should You Consider NFLOG?

NFLOG becomes particularly useful when you need:

dedicated firewall logging
centralized processing
structured packet-event handling
separation from general kernel logs
integration with userspace logging systems

For a small Linux router, ordinary rate-limited logging may be sufficient.

For larger environments, NFLOG can provide a cleaner architecture.

Logging vs Firewall Verdict

Remember:

LOG

is not automatically:

DROP

and it is not automatically:

ACCEPT

Think:

Packet
   ↓
Observation
   ↓
Policy Decision

These are separate functions.

Keeping them conceptually separate prevents subtle rule-design mistakes.

Logging DNAT and Port Forwarding Traffic

Suppose your Linux firewall publishes:

Public:
203.0.113.10:443

        ↓ DNAT

Backend:
192.168.20.10:443

The packet passes through:

WAN
 ↓
PREROUTING
 ↓
DNAT
 ↓
Routing
 ↓
FORWARD
 ↓
DMZ

At different hooks, nftables may evaluate different address information because DNAT has already modified the destination.

This matters when creating logging rules.

If you try to match:

203.0.113.10

at a stage where the packet destination is already:

192.168.20.10

your rule may never match.

Before logging NAT traffic, understand the exact packet path.

The complete workflow is covered in nftables DNAT Port Forwarding Not Working.

Logging Hairpin NAT Traffic

Hairpin NAT introduces an additional path:

Internal Client
      ↓
Public IP
      ↓
DNAT
      ↓
Internal Server

and some topologies also require:

SNAT / masquerade

to keep the return path through the NAT router.

For this traffic, useful monitoring points include:

DNAT counter
SNAT counter
NEW connection logging
FORWARD counter
conntrack entry

rather than logging every packet.

See nftables Hairpin NAT and NAT Loopback for the complete packet-path explanation.

Logging Inter-VLAN Firewall Traffic

Consider:

VLAN 10
Users
192.168.10.0/24

VLAN 20
Servers
192.168.20.0/24

VLAN 30
Management
192.168.30.0/24

The security policy might be:

Users
   ↓
HTTPS
   ↓
Servers

while:

Users
   X
SSH
   X
Servers

and:

Management
     ↓
SSH
     ↓
Servers

Rather than logging every permitted HTTPS packet, a more valuable event might be:

User VLAN attempted SSH to Server VLAN

A controlled logging rule could identify those attempts.

For example:

ip saddr 192.168.10.0/24 \
ip daddr 192.168.20.0/24 \
tcp dport 22 \
limit rate 5/minute \
log prefix "NFT_USERS_SSH_DENIED: "

followed by the appropriate deny policy.

This provides useful security visibility without filling logs with normal application traffic.

For the underlying segmentation model, see Linux nftables Inter-VLAN Firewall.

Logging a Linux DMZ

A production DMZ might permit:

Internet
   ↓
TCP/443
   ↓
Web Server

while denying:

Internet
   ↓
Other unsolicited services

and:

DMZ
 X
LAN

unless an explicit application dependency exists.

Useful logging candidates therefore include:

unexpected WAN → DMZ traffic

DMZ → LAN attempts

INVALID packets

new administrative connections

unexpected published-service traffic

rather than every normal packet.

This matches the segmentation architecture developed in Linux DMZ with nftables.

nftables Rate Limiting Beyond Logging

The limit mechanism is not exclusively a logging feature.

It can participate in firewall policies that control how frequently certain traffic is permitted to match.

But it is important not to overstate what it provides.

An nftables rate limiter is not automatically a:

Web Application Firewall

complete DDoS protection platform

application-level authentication system

intrusion detection system

It operates at the firewall/network layer according to the rules you configure.

Rate Limiting SSH Attempts

SSH is a common example.

Suppose you want to restrict excessive new connection attempts.

The relevant event is typically:

ct state new
+
tcp dport 22

rather than every packet in an established SSH session.

However, you must decide whether you mean:

global rate limit

or:

per-source rate limit

These are fundamentally different.

Global Rate Limit vs Per-Source Rate Limit

Suppose you configure:

limit rate 10/minute

in a rule.

Conceptually, this can represent a shared rate limit for traffic matching that rule.

Imagine three legitimate administrators:

Admin A
Admin B
Admin C

If they share the same global allowance, one source can consume capacity affecting the others.

But perhaps your intended policy is:

Admin A → own limit
Admin B → own limit
Admin C → own limit

That requires state keyed by source rather than merely one global limiter.

For advanced per-source control, nftables dynamic sets and meters are more appropriate tools.

This distinction is particularly important for SSH and abuse-control rules.

Do Not Lock Yourself Out of SSH

When modifying remote administration rules, proceed carefully.

A mistake involving:

SSH
+
rate limit
+
default drop

can lock you out of a remote server.

Before changing production SSH policy, ensure you have an appropriate recovery method such as:

console access
hosting control panel
out-of-band management
tested secondary administrative path

Do not replace a working remote-management rule with an untested rate-limiting configuration.

nftables Logging with Sets

Sets can improve both firewall performance and readability.

Instead of repeating:

192.168.30.10
192.168.30.11
192.168.30.12

you might maintain:

@management_hosts

Likewise:

@web_servers

can represent several destination systems.

The policy becomes conceptually:

@management_hosts
       ↓
SSH
       ↓
@servers

Logging then reflects a security relationship rather than dozens of duplicated IP-specific rules.

Dynamic Sets for Per-Source Controls

Dynamic sets can maintain temporary state based on packet attributes such as source addresses.

This enables architectures such as:

Source IP
    ↓
Connection attempt
    ↓
Dynamic tracking
    ↓
Threshold
    ↓
Policy action

This can provide more sophisticated per-source controls than a single global rate limit.

However, maintainability matters.

Do not turn a straightforward firewall into an undocumented pseudo-IDS containing dozens of opaque dynamic expressions.

nftables Logging vs tcpdump

This is a common troubleshooting question.

They are not alternatives.

nftables logging asks:

Did this traffic match a specific firewall rule or condition?

tcpdump asks:

Did I observe this packet at this capture point?

For example:

sudo tcpdump -ni eth0 tcp port 443

may prove that the WAN interface receives an HTTPS SYN.

But it does not by itself tell you which nftables rule produced the final verdict.

Conversely, a firewall log does not replace detailed packet capture.

Use them together.

nftables Counters vs tcpdump

Suppose:

tcpdump sees SYN

but:

expected ACCEPT counter = 0

This is extremely useful evidence.

It suggests the packet exists, but the rule you expected is not matching it.

Now investigate:

source address
destination address
input interface
protocol
port
conntrack state
rule order

instead of changing the application.

Add Conntrack to the Troubleshooting Stack

A high-quality firewall investigation combines several perspectives:

tcpdump
   ↓
Did the packet arrive?


nftables counter
   ↓
Which rule matched?


conntrack
   ↓
What state/flow exists?


nftables log
   ↓
What event details were recorded?


trace
   ↓
How did the packet move through the ruleset?

This is why the nftables Conntrack States and Troubleshooting article is an important companion to this guide.

Debug Complex Rules with nft monitor trace

When counters and logs are insufficient, packet tracing can show how nftables evaluates traffic.

The official nftables ruleset tracing documentation explains how nftrace and:

sudo nft monitor trace

can be used to follow selected packets through the ruleset.

Conceptually:

Packet
   ↓
PREROUTING
   ↓
rule evaluation
   ↓
routing
   ↓
FORWARD
   ↓
rule evaluation
   ↓
POSTROUTING

This becomes particularly useful when the ruleset contains:

jump chains
sets
maps
NAT
VLANs
multiple interfaces
complex state rules

Never Trace Everything on a Busy Firewall

Just as you should avoid logging everything, avoid enabling broad tracing on a production router without a clear reason.

First identify:

source
destination
protocol
port

then trace the narrow flow you need.

Good observability means high signal, not maximum output.

nftables Logging and Flow Offload

Advanced Linux routers may use Netfilter flowtables to accelerate forwarded connections.

This matters for troubleshooting because eligible traffic can enter a fast path after the initial packets.

The official Linux kernel Netfilter flowtable documentation explains that flowtable entries can provide a faster forwarding path and retain NAT information.

Consequently, a classic forwarding-rule counter may not necessarily increment for every packet after a flow is offloaded.

If:

connection works

but:

expected counter stops increasing normally

check whether flow offloading is active before concluding that nftables is losing traffic.

A Complete nftables Troubleshooting Workflow

When traffic unexpectedly fails, use a repeatable workflow.

1. Identify source and destination
              ↓
2. Verify routing
              ↓
3. Capture traffic
              ↓
4. Inspect nftables counters
              ↓
5. Inspect conntrack
              ↓
6. Inspect rate-limited logs
              ↓
7. Trace the flow if necessary
              ↓
8. Identify the exact failure point
              ↓
9. Change the smallest possible configuration
              ↓
10. Retest

This is much more reliable than:

add ACCEPT rule
test
add NAT
test
disable firewall
test
flush rules
test

Random changes destroy evidence and can create new problems.

Practical Troubleshooting Example

Assume:

Client:
192.168.10.50

Server:
192.168.20.10

Service:
TCP/443

The client reports a timeout.

Start with routing:

ip route get 192.168.20.10

Capture the flow:

sudo tcpdump -ni any \
host 192.168.20.10 and tcp port 443

Inspect firewall counters:

sudo nft -a list chain inet firewall forward

Inspect connection tracking:

sudo conntrack -L -p tcp | grep 192.168.20.10

Inspect controlled firewall logs:

journalctl -k | grep NFT_

If necessary, trace only the relevant flow.

You now have evidence from:

routing
packet capture
firewall rules
connection tracking
logging

rather than one vague symptom.

Scenario 1: tcpdump Sees the Packet but the ACCEPT Counter Is Zero

The packet reaches the system.

Your expected rule does not appear to match.

Investigate:

wrong source
wrong destination
wrong port
wrong interface
wrong chain
unexpected conntrack state
earlier rule

Do not immediately blame the application.

Scenario 2: DROP Counter Is Increasing Rapidly

First determine what is being dropped.

Use temporary controlled logging such as:

limit rate 5/second \
log prefix "NFT_DEBUG_DROP: "

Then inspect:

source IP
destination IP
protocol
port
interface
conntrack state

The traffic could represent:

port scanning
misconfigured software
incorrect routing
monitoring traffic
undocumented application dependency
expired connection state

The counter alone cannot tell you which.

Scenario 3: INVALID Traffic Suddenly Increases

Do not immediately remove:

ct state invalid drop

Combine:

counter
+
rate-limited logging
+
tcpdump
+
conntrack

and inspect routing.

If the system has multiple gateways, use Linux Policy Routing with ip rule and Multiple Routing Tables.

If replies return through another path, see Linux rp_filter and Asymmetric Routing.

If Linux simply chooses an unexpected interface, see Linux Traffic Uses the Wrong Interface.

A firewall symptom can originate in the routing layer.

Scenario 4: DNAT Counter Increases but the Connection Still Fails

Follow the complete path:

DNAT counter
      ↓
FORWARD counter
      ↓
DMZ interface
      ↓
Server
      ↓
Server response
      ↓
Return route
      ↓
Conntrack

If normal external port forwarding fails, use nftables DNAT Port Forwarding Not Working.

If external clients work but internal clients cannot reach the service through its public IP, use nftables Hairpin NAT and NAT Loopback.

Production nftables Logging Strategy

A scalable firewall-monitoring design can use four levels:

LEVEL 1
Counters
   ↓
Broad statistics


LEVEL 2
Rate-limited logs
   ↓
Important events


LEVEL 3
NFLOG / centralized processing
   ↓
Security monitoring


LEVEL 4
tcpdump + nft trace
   ↓
Temporary deep troubleshooting

This gives you observability without turning the firewall into a packet-by-packet logging system.

What Should You Log?

High-value candidates include:

unexpected WAN input

blocked management access

new connections to sensitive services

DMZ → LAN violations

unexpected inter-VLAN access

INVALID traffic

selected NAT failures

These events tell you something meaningful about the network or security policy.

What Should You Usually Not Log?

Avoid continuously logging:

every established HTTPS packet

every DNS response

every normal LAN packet

every permitted application packet

unless you have a specific compliance or investigative requirement.

Counters are usually better for normal traffic volume.

Design Logging Around Security Zones

Suppose your firewall contains:

WAN
LAN
DMZ
MANAGEMENT
VPN

Create log prefixes that reflect those relationships:

NFT_WAN_INPUT_DROP

NFT_WAN_DMZ_DENIED

NFT_DMZ_LAN_DENIED

NFT_LAN_MGMT_DENIED

NFT_VPN_INVALID

Now a log entry tells you immediately which policy boundary was involved.

This is far better than:

DROP RULE 12

Example Production Firewall Pattern

A simplified design could look like:

table inet firewall {

    chain forward {

        type filter hook forward priority filter;
        policy drop;

        # Log a controlled sample of INVALID packets
        ct state invalid \
        limit rate 5/second \
        log prefix "NFT_INVALID: "

        # Drop every INVALID packet
        ct state invalid counter drop

        # Permit known flows
        ct state established,related counter accept

        # Explicit NEW connection policies go here

        # Log a controlled sample of remaining drops
        limit rate 5/second \
        log prefix "NFT_FORWARD_DROP: "

        # Drop everything else
        counter drop
    }
}

This example illustrates the architecture rather than serving as a universal copy-and-paste firewall.

A production ruleset should reflect your actual:

interfaces
subnets
security zones
applications
IPv4 policy
IPv6 policy
management requirements

Protect Firewall Logs as Security Data

Firewall logs can reveal:

internal addresses
server addresses
open services
network topology
administrative activity
connection attempts
security policy

Treat them as sensitive operational data.

Your logging architecture should therefore consider:

access control
retention
rotation
storage
centralization
backup
privacy

A logging system is itself part of the security architecture.

Common nftables Logging Mistakes

The most common mistakes are easy to avoid:

  1. Logging every packet. Use counters for ordinary volume and logs for meaningful events.
  2. No logging rate limit. Internet-facing drop rules can produce enormous log volumes.
  3. Rate-limiting the drop instead of the log. Make sure every prohibited packet still receives the intended verdict.
  4. Logging every ESTABLISHED packet. Usually log new or exceptional events instead.
  5. Using meaningless prefixes. NFT_DMZ_LAN_DENIED is much more useful than DROP3.
  6. Using logging when a counter would answer the question. If you only need to know whether a rule matches, start with counter.
  7. Treating logging as a replacement for tcpdump. Firewall events and packet capture provide different information.
  8. Ignoring conntrack state. The missing clue may be NEW, ESTABLISHED, RELATED, or INVALID.
  9. Ignoring routing. A firewall drop can be the downstream symptom of a routing problem.
  10. Changing multiple rules at once. Preserve evidence and make the smallest necessary change.

Frequently Asked Questions

How do I log dropped packets in nftables?

Use the log statement before the drop verdict, for example:

log prefix "NFT_DROP: " drop

On production systems, consider rate-limiting the logging to prevent excessive log volume.

How do I rate-limit nftables logging?

A basic example is:

limit rate 5/second log prefix "NFT_DROP: "

If all matching traffic must still be dropped, use a separate unconditional drop rule afterward so the limit controls logging rather than the security verdict.

What does counter do in nftables?

counter records the number of packets and bytes matching a rule.

It is one of the most useful tools for determining whether traffic reaches the rule you expect.

Should I use counter or log?

Use counter when you need volume or rule-hit information.

Use log when you need information about individual matching events.

Many production firewalls use both.

Should I log all firewall drops?

Usually not without rate limiting.

Internet-facing systems may receive large amounts of unwanted traffic, making unrestricted logging noisy and potentially expensive.

Should I log ESTABLISHED connections?

Usually not every packet.

A better strategy is often to count established traffic and selectively log new or security-sensitive connection events.

What is NFLOG?

NFLOG is a Netfilter mechanism that allows packet logging information to be delivered to userspace through logging groups.

It can be useful for dedicated or centralized firewall logging architectures.

How do I view nftables logs?

On many systemd-based Linux systems, kernel firewall messages can be inspected with:

journalctl -k

If you use a prefix:

journalctl -k | grep NFT_

can help filter firewall events.

The exact logging destination depends on the system’s logging configuration.

Can nftables rate-limit SSH?

Yes, but determine whether you require a global rate limit or a per-source limit.

A basic limit rule is not automatically equivalent to per-client rate limiting.

Dynamic sets or meters may be more appropriate for per-source policies.

Why is my nftables rule counter not increasing?

Possible causes include:

packet never reaches the system
wrong chain or hook
wrong interface
rule does not match
earlier rule handles the traffic
different address after NAT
flow offloading

Use tcpdump, counters, conntrack, and targeted tracing to identify the actual path.

What is the best way to debug nftables?

A strong workflow is:

Routing
   ↓
tcpdump
   ↓
nftables counters
   ↓
conntrack
   ↓
rate-limited logs
   ↓
nft monitor trace

Each tool answers a different question.

Final Troubleshooting Checklist

Before modifying a production firewall, verify:

□ Does the packet reach the expected interface?

□ Does Linux select the correct route?

□ Does the expected nftables counter increase?

□ What conntrack state does the packet have?

□ Is another rule matching first?

□ Has NAT changed the address before the rule being inspected?

□ Are firewall logs rate-limited?

□ Does the destination server receive the packet?

□ Does the destination send a response?

□ Does the response return through the expected path?

□ Is flow offloading active?

□ Would targeted nftables tracing provide the missing evidence?

This checklist converts a vague problem such as:

“The firewall is blocking my connection.”

into a repeatable engineering process.

Conclusion

nftables logging and rate limiting are most effective when they are part of a broader firewall observability strategy rather than used in isolation.

A mature Linux firewall should not simply answer:

ACCEPT

or:

DROP

It should give administrators enough evidence to understand why the decision occurred.

A useful troubleshooting model is:

                 PACKET
                    ↓
                 ROUTING
                    ↓
                CONNTRACK
                    ↓
                NFTABLES
                    ↓
        ┌───────────┼───────────┐
        ↓           ↓           ↓
     COUNTER       LOG        VERDICT
        ↓           ↓           ↓
   Statistics   Evidence   ACCEPT/DROP
                    ↓
               Rate Limit

Use counters to measure rule activity.

Use rate-limited logs to capture significant events.

Use NFLOG when a dedicated userspace logging architecture is appropriate.

Use conntrack to understand connection state.

Use tcpdump to verify packet movement.

And use nft monitor trace when the ruleset itself is the mystery.

The official nftables logging documentation explains the log statement and NFLOG functionality, while the official rate-limiting documentation covers the limit mechanism. For statistics, the official nftables Counters documentation explains anonymous and named counters, while difficult packet-path problems can be investigated with the official nftables ruleset tracing guide.

Within the CorgiNetwork Linux networking cluster, combine this guide with nftables Conntrack States and Troubleshooting when investigating NEW, ESTABLISHED, RELATED, or INVALID traffic.

For segmentation, continue with Linux nftables Inter-VLAN Firewall and Linux DMZ with nftables.

For published services, use nftables DNAT Port Forwarding Not Working, while internal clients accessing those services through their public address should be diagnosed with nftables Hairpin NAT and NAT Loopback.

If the firewall symptoms originate in routing, continue with Linux Traffic Uses the Wrong Interface, Linux rp_filter and Asymmetric Routing, and Linux Policy Routing with ip rule and Multiple Routing Tables.

Together, these articles create a tightly connected technical cluster:

Linux Routing
      ↓
Policy Routing
      ↓
VLANs
      ↓
Inter-VLAN Routing
      ↓
Stateful nftables
      ↓
DMZ
      ↓
DNAT
      ↓
Hairpin NAT
      ↓
Conntrack
      ↓
Logging & Counters
      ↓
Rate Limiting
      ↓
Advanced Firewall Observability

The principle worth remembering is:

Do not log everything. Log the events that explain your firewall, count the traffic that measures it, and trace only the packets you need to investigate.

Leave a Reply

Your email address will not be published. Required fields are marked *