NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will configure and verify a basic Encrypted Traffic Analytics (ETA) workflow that analyzes encrypted TLS traffic without decryption by exporting TLS metadata (via NetFlow/IPFIX) to an analytics collector. This matters because in production networks you can detect malware, data exfiltration, and anomalous encrypted sessions without breaking privacy or introducing decryption overhead. Real-world scenario: a campus edge router exports TLS handshake metadata to an ETA collector so the security team can detect suspicious TLS fingerprints (JA3) and prioritize investigations.

Quick Recap

Refer to the topology used in Lesson 1. This lesson does not add new routers or switches; it introduces an ETA collector on the management VLAN. The following new IP is added for the ETA collector (used throughout the lab):

ETA collector: 10.1.1.10/24

All other device IPs and interface names remain as shown in Lesson 1.

Important: This lab focuses on exporting TLS metadata (via NetFlow/IPFIX) from the network edge to a collector for ML-based analysis. We do NOT decrypt TLS — ETA infers malicious behavior from metadata.

Topology (ASCII)

Note: show the existing topology from Lesson 1 — here is the segment relevant to ETA with exact IPs on each interface.

R1 (edge router) and ETA collector on the management VLAN:

[Internet]
   |
   | 192.0.2.2
   |
R1 GigabitEthernet0/0 192.0.2.1/30
R1 GigabitEthernet0/1 10.1.1.1/24 --- Switch --- Hosts
                               |
                               | 10.1.1.10/24
                         ETA Collector (10.1.1.10)

Device Table

Device	Role	Interface / IP
R1	Edge Router exporting NetFlow/IPFIX	Gi0/0 192.0.2.1/30, Gi0/1 10.1.1.1/24
ETA-1	ETA collector / analytics	eth0 10.1.1.10/24

Key Concepts

Encrypted Traffic Analytics (ETA): ETA inspects TLS handshake metadata (not the encrypted payload) and uses fingerprints such as JA3/JA3S combined with telemetry (SNI, cipher suites, client/public key lengths, TLS version) to classify encrypted sessions. Think of it as profiling the "envelope" instead of opening the letter.
NetFlow/IPFIX export: Routers and some middleboxes can export flow records to a collector. For ETA, the exported fields include TLS-related metadata (when supported). NetFlow export is like sending summarized postcards about each conversation — who talked to whom, when, and a few characteristics of the "voice" used (TLS metadata).
JA3 fingerprinting and TLS handshake behavior: The TLS ClientHello contains reproducible fields (cipher suites, extensions, elliptic curve lists) that are hashed to create a JA3 fingerprint. When a client sends ClientHello, the device that sees it can extract these fields and export them in IPFIX/NetFlow. When these fingerprints correlate with known malicious fingerprints, ETA can flag the flow.
Privacy and performance: ETA avoids decryption; it analyzes metadata only. This is especially valuable when decryption is infeasible (large scale, privacy rules, or widespread TLS traffic). In production, this reduces CPU cost and legal exposure.
Packet flow for ETA: Client -> Edge Router sees ClientHello -> Router extracts TLS metadata -> Router exports NetFlow/IPFIX to ETA collector -> Collector applies ML/heuristics and raises alerts or enriches SIEM.

Step-by-step configuration

We will configure NetFlow/IPFIX on the edge router (R1) to export flow records to the ETA collector (10.1.1.10) and verify flows reach the collector.

Step 1: Configure NetFlow/IPFIX export destination on R1

What we are doing: We tell the router to export flow records (IPFIX/NetFlow) to the ETA collector IP. This is the core telemetry path; without it the collector cannot receive TLS metadata.

configure terminal
ip flow-export destination 10.1.1.10 4739
ip flow-export version 9
ip flow-export source GigabitEthernet0/1
end

What just happened:

ip flow-export destination 10.1.1.10 4739 configures the collector UDP endpoint and port (4739 commonly used for IPFIX).
ip flow-export version 9 sets NetFlow version 9, which supports extensible templates for TLS/IPFIX fields.
ip flow-export source GigabitEthernet0/1 ensures flow export packets use the internal interface IP (10.1.1.1) as source so the collector can reply/associate flows. These commands enable the router to package and send flow data that includes TLS metadata (when supported by platform).

Real-world note: In production, use an IP address reachable from the router, and secure the transport if supported (e.g., TLS for IPFIX) or place collector in a management VLAN.

Verify:

show ip flow export
Exporting flows to 10.1.1.10 (udp port 4739)
Exporting using source interface GigabitEthernet0/1
Flow export version 9
Records Exported: 124
Packets Sent: 125
Flow Created: 01:23:45
Template last sent: 00:00:10

Expected output shows the destination, source interface, flow export version, and counters. If counters increment during traffic, export is functioning.

Step 2: Enable NetFlow on the ingress interface (capture flows)

What we are doing: We enable NetFlow collection on the interface that sees client-originated TLS traffic so the router generates flow records for those sessions.

configure terminal
interface GigabitEthernet0/1
 ip flow ingress
 exit
end

What just happened:

ip flow ingress turns on flow sampling/instrumentation for packets entering Gi0/1; the router now builds flow cache entries for those packets. For TLS flows, the router will observe the ClientHello and include available TLS metadata in templates if the platform supports extended fields.

Real-world note: Apply NetFlow only on necessary interfaces to minimize CPU/memory impact. In high-throughput environments, sample flows rather than capture all traffic.

Verify:

show ip cache flow
IP packet size distribution (2048 bytes)
Protocol  Total Flows  Active Flows  Flows/sec  Active Inserts
tcp       120          3             0.03       0
udp       10           0             0.01       0
Total flows: 130

Expected output provides flow cache statistics. Presence of TCP flows indicates NetFlow is capturing traffic. If no flows appear, generate traffic from hosts.

Step 3: Confirm that TLS metadata templates are being sent (NetFlow templates)

What we are doing: We verify the router is sending template records (NetFlow v9 templates) that define which fields are exported; ETA collectors require templates that include TLS-related fields (if supported).

show ip flow export templates
Template ID: 256
Fields: srcAddr, dstAddr, srcPort, dstPort, protocol, tcpFlags, flowStartMilliseconds, flowEndMilliseconds, tlsClientHelloJA3, tlsServerHelloJA3, tlsSNI
Last Template Sent: 00:00:10

What just happened:

The router reports a template that includes TLS metadata fields such as JA3 and SNI. Templates describe the structure of subsequent flow records so the collector can decode TLS fingerprints.

Real-world note: Not all platforms support TLS extension fields. If the router/platform does not expose these fields, consider placing an SSL-aware sensor or using a firewall that supports ETA-specific metadata export.

Verify:

show ip flow export templates
Template ID: 256
Fields: srcAddr, dstAddr, srcPort, dstPort, protocol, tcpFlags, flowStartMilliseconds, flowEndMilliseconds, tlsClientHelloJA3, tlsServerHelloJA3, tlsSNI
Last Template Sent: 00:00:10

Expected output must list TLS-related fields. If missing, the collector cannot perform JA3-based classification from this router.

Step 4: Verify the collector is receiving flow packets (collector-side)

What we are doing: On the ETA collector, verify it receives IPFIX/NetFlow UDP packets from the router and that templates/records are parsed. This proves the end-to-end telemetry pipeline.

(Collector) sudo tcpdump -nni eth0 udp port 4739
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:15:01.123456 IP 10.1.1.1.4739 > 10.1.1.10.4739: UDP, length 512
09:15:01.223456 IP 10.1.1.1.4739 > 10.1.1.10.4739: UDP, length 420

What just happened:

The collector sees UDP packets from the router (source 10.1.1.1) to UDP port 4739. Each packet contains either templates or flow records. A functioning export means the collector can decode templates and extract JA3/SNI fields for ML processing.

Real-world note: In production, run the collector on a hardened host and restrict access. Persistent packet drops may indicate MTU or firewall issues.

Verify:

(Collector) netstat -anu | grep 4739
udp        0      0 0.0.0.0:4739            0.0.0.0:*

Expected output shows a listener on UDP 4739. Higher-level ETA software will show received templates and decoded JA3 fingerprints.

Step 5: Generate test TLS traffic and validate ETA insights

What we are doing: Create TLS sessions from a client to public web servers and observe decoded JA3 fingerprints on the collector and any ETA alerts. This step validates that TLS metadata is correctly captured and analyzed.

(Client) curl -sI https://lab.nhprep.com/
HTTP/2 200
date: Thu, 01 Apr 2026 09:20:00 GMT
server: nginx
...

What just happened:

The client initiated a TLS handshake; the edge router observed the ClientHello and exported a flow record containing the JA3 fingerprint and SNI "lab.nhprep.com". The collector decoded the record and either matched it against known benign/malicious fingerprints or queued it for ML analysis.

Real-world note: Use representative client software (browsers, SDKs) in tests because different TLS clients produce different JA3 fingerprints.

Verify:

(Collector) eta-analytics-cli show recent-flows | head -n 5
Time: 2026-04-01T09:20:00Z  Src: 10.1.1.100:52344  Dst: 93.184.216.34:443  JA3: d4e7a2f5...  SNI: lab.nhprep.com  Verdict: benign  Confidence: 95%
Time: 2026-04-01T09:20:05Z  Src: 10.1.1.101:52345  Dst: 198.51.100.5:443  JA3: a9c1b2d3...  SNI: suspicious.example  Verdict: suspicious  Confidence: 78%

Expected output shows decoded flow records with JA3, SNI, and any ETA verdicts. If no records appear, re-check flow export templates and network reachability.

Verification Checklist

Check 1: Router exports NetFlow to the collector. Verify with show ip flow export and confirm destination is 10.1.1.10:4739 and counters increment.
Check 2: Interface flow cache populates. Verify with show ip cache flow — you should see active TCP flows corresponding to client TLS sessions.
Check 3: Collector receives and parses templates and flow records. Verify using packet capture (collector) and analytics tool output showing JA3/SNI fields and verdicts.

Common Mistakes

Symptom	Cause	Fix
No NetFlow packets reach collector	ACL/firewall or routing blocks UDP 4739	Ensure routing and ACLs allow UDP 4739 from router to collector; test with ping and tcpdump
Templates exist but no TLS fields	Platform does not support TLS export or NetFlow version mismatch	Confirm device supports TLS fields; use NetFlow v9/IPFIX and update platform or use an ETA-capable sensor
Flow counters do not increment	NetFlow not enabled on correct interface or interface has no traffic	Apply `ip flow ingress` on the interface seeing client traffic and generate test TLS traffic
Collector shows records but no JA3/SNI	Collector parsing not configured or templates not matched	Confirm templates received (template IDs) and configure collector to parse TLS fields per template definition

Key Takeaways

ETA analyzes TLS metadata (e.g., JA3 fingerprints, SNI, ciphers) — it does not decrypt traffic. This preserves privacy while enabling detection of malicious encrypted sessions.
NetFlow/IPFIX export is the transport for TLS metadata from network devices to the collector; proper template support (v9/IPFIX) is essential.
In production, place the collector in a secure management network, protect telemetry channels, and sample flows to balance observability versus device load.
If a network device does not natively export TLS metadata, consider deploying sensors or NGFWs that do, and always validate end-to-end: router -> collector -> analytics verdicts.

Tip: Treat ETA as a detection amplifier — it prioritizes suspicious encrypted connections for follow-up (packet capture, endpoint checks) rather than as a definitive block.