Sensor Selection Is a Security Decision

Most environments treat monitoring as an afterthought — throw SNMP at everything, watch the uptime graph, call it done. The problem is that SNMP tells you a device is alive and its CPU isn't pegged. It tells you almost nothing about what traffic is actually traversing your network, who's talking to whom, and whether that pattern looks normal. This post documents standing up IPFIX flow collection feeding into PRTG, and the lessons that came out of a surprisingly painful configuration process.

SNMP vs NetFlow/IPFIX: Why It Matters for Security

SNMP gives you device health: interface counters, CPU, memory, uptime. It's valuable for capacity planning and availability monitoring. But when you're trying to detect a compromised host beaconing to a C2, or a user exfiltrating data to personal cloud storage, or a lateral movement sweep across your subnet — SNMP is blind to all of it.

NetFlow/IPFIX gives you traffic metadata: source IP, destination IP, port, protocol, byte counts, packet counts, timing. You can reconstruct the conversation graph of your entire network. Anomalies — a workstation that suddenly starts making hundreds of outbound DNS requests, or a server that's never talked to Eastern Europe starting to do so at 3am — become visible.

Choosing SNMP-only monitoring is a security decision, even if it doesn't feel like one. You are choosing visibility into device health over visibility into traffic behavior.

The Environment

• →PRTG Network Monitor (free tier) installed on a Windows machine at your IP of choice
• →Test your firewall at your gateway IP

Lesson 1: IPFIX-with-Extensions Will Silently Break Your Collector

PRTG cannot parse proprietary extension fields. The collector receives the packets, can't interpret the template, and silently drops the flow records. The sensor shows as receiving data, but the data is unusable.

Lesson 2: A Gray Sensor Is Not the Same as a Misconfigured Sensor

A gray PRTG sensor means "no data received." This is ambiguous — it could mean the exporter isn't sending, the collector isn't listening, there's a firewall rule in the way, or the sensor is pointed at the wrong IP. We worked through all of these systematically:

1. 01Is PRTG actually listening on UDP 2055? — netstat -an | findstr 2055 on the PRTG machine. If nothing shows, PRTG isn't bound to that port.
2. 02Is the firewall actually sending? — Use your firewalls built-in packet capture tool to confirm UDP packets are leaving the firewall toward the collector IP on port 2055.
3. 03Is Windows Firewall blocking the port? — Temporarily disable Windows Defender Firewall entirely to isolate this variable. If the sensor goes green, add a permanent inbound rule for UDP 2055.
4. 04Is the sensor placed under the probe device, not a monitored device? — IPFIX sensors in PRTG must be under the probe server itself, not under a device entry representing the firewall.

Lesson 3: Test Appliances Without Working NAT Generate No Flow Records

Template Generation: Enable Periodic Resend

IPFIX requires the exporter to send template records before flow records can be decoded. By default on some firewall firmware versions, "Send IPFIX/NetFlow Templates At Regular Interval" is disabled — meaning if the collector restarts or the template is lost, new flow records arrive without the decoder knowing what they mean. Enable this setting. It has no meaningful performance cost and saves you from mysterious gray sensors after service restarts.

Port Reference