Skip to content

Packet Filter

Packet Filter

Introduction

Packet filter audit events on IRF1000 and IRF3000 indicate that forwarded Layer‑3 traffic matched a packet filter rule with the Audit option enabled. The event records the IPv4 source address, destination address, and protocol of the forwarded packet and makes this visible both in the web interface and in audit.log.

These events help you confirm expected communication paths in OT networks and detect unexpected peers or protocols that reach critical assets. Do not use this event type for full traffic accounting, because logging is rate‑limited to one message per minute per audited rule. For security monitoring, correlate these sampled events with your firewall rules and with dedicated flow or packet monitoring where required.

Webinterface View

The VIEW web interface shows these events in the Packet filter audit section. The web view reads NETFILTER_PKT entries from audit.log, extracts the relevant fields, and converts the numeric protocol value into a protocol name, for example 1 to icmp or 6 to tcp. Only forward‑path hits are displayed. Rule names, ports, interfaces, and actions are not shown.

The table columns in the web interface have the following meaning:

Field Description Example
Date Device local calendar date when the audit event was recorded. 10/15/25
Time Device local time when the audit event was recorded. 09:46:26
Source address IPv4 source address of the forwarded packet. 172.16.0.40
Destination address IPv4 destination address of the forwarded packet. 192.168.0.253
Protocol IP protocol name derived from the numeric proto field in the audit record. icmp / tcp

Entries in this view are sampled because of the rate limit. If a large number of packets match the same audited rule, you still see at most one row per minute for that rule. For SIEM or SOC integration, use the raw audit.log file as the primary data source and treat the web view as a human‑readable summary.

Explanation of the raw audit.log entry

Lines with type=NETFILTER_PKT in audit.log are created by the kernel netfilter audit integration via the iptables audit extension. Each line contains basic packet metadata. Rule names and explicit actions are not part of this record. Generic auditd fields behave as documented in the standard auditd manuals and are not described in detail here.

A typical NETFILTER_PKT record looks like this and contains the following components:

Field Description Example
type Audit record type. For packet filter audit events this is NETFILTER_PKT. type=NETFILTER_PKT
msg Audit metadata with timestamp and record ID in auditd format. msg=audit(1760514386.800:94)
mark Netfilter mark value if present. The IRF does not change this by default. mark=0x0
saddr Source IPv4 address of the forwarded packet. saddr=172.16.0.40
daddr Destination IPv4 address of the forwarded packet. daddr=192.168.0.253
proto IP protocol number as assigned by IANA (for example 1 = ICMP, 6 = TCP, 17 = UDP). proto=1 / proto=6

For SIEM or SOC use, filter for type=NETFILTER_PKT, extract saddr, daddr, and proto, and map the protocol numbers to protocol names using the official IANA protocol list. Remember that these records are rate‑limited to one message per minute per audited rule, so they represent sampled matches and not every packet that traverses the rule.

When the event is generated

A NETFILTER_PKT audit event is generated only under specific technical conditions on the IRF device.

  1. A packet traverses the Linux netfilter FORWARD path on the IRF. This means the device forwards the packet between two networks; it is not traffic that terminates on the IRF itself.
  2. The packet matches a configured Layer‑3 packet filter rule where the Audit checkbox is enabled in the rule definition.
  3. The packet is IPv4 Layer‑3 traffic. The current implementation covers only forwarded IPv4 packets.

For such a rule the IRF creates an iptables chain and inserts a jump to the AUDIT target. When a packet enters this chain, the iptables audit extension sends packet metadata to the audit subsystem, which then writes a NETFILTER_PKT record to audit.log. Rule names are not included in the record. To protect the device and log storage from overload, the logging is rate‑limited to at most one message per minute per audited rule, even if many packets match during that minute.

Sample audit.log entry

(1) type=NETFILTER_PKT msg=audit(1760514386.800:94): mark=0x0 saddr=172.16.0.40 daddr=192.168.0.253 proto=1
(2) type=NETFILTER_PKT msg=audit(1760515499.024:96): mark=0x0 saddr=172.16.0.40 daddr=192.168.0.253 proto=6