Arkime Architecture

Here are some sample deployments of Arkime for different network architectures. Most folks will probably run a hybrid of the following since no one solution fits all. The ability to scale capturing can be done horizontally by adding more capture machines, vertically by adding more cpus/disk, or both. We usually recommend scaling horizontally unless physically space constrained, and using a network packet broker in front of multiple machines. However it is possible to use big machines, with lots of cpu/disk, and run arkime-capture with more threads. There is a companion video for this page.

Legend / Info

A box represents a physical machine.
It is possible to run multiple capture processes per machine, or have a single capture process listen to multiple interfaces - (FAQ Answer)
Recommend “Big Data” style boxes for capture - (FAQ Answer)
Run multiple OpenSearch/Elasticsearch processes per machine since each ES node should be configured at most to 30G - (FAQ Answer)
Except for single host deployments, it is recommended/useful that all operator access flows through a central viewer with potentially a reverse proxy that can provide enterprise level authentication, logging, and a single choke point - (FAQ Answer)

Security

All ES instances should have iptables for port 9200-920N and 9300-930N, where N is the number of ES instances per machine, and only allow the other OpenSearch/Elasticsearch, capture and viewer machines to connect
All viewer hosts, except the central viewer box, should have iptables for port 8005 and only allow other viewer machines to connect. The viewer must listen on OS interface if using multiple machines
The shared viewer instances can listen on localhost since only reverse proxy talks to it

Single Host

Capture, viewer, WISE and both data stores all live on one machine.

A single host deployment should usually only be used for demos and extremely low traffic networks. The read/write patterns of Arkime vs OpenSearch/Elasticsearch will tax most systems using spinning disks and is not recommended.

Multiple Hosts Monitoring Multiple Network Segments

Each segment gets its own capture node; operators reach every cluster through a single reverse‑proxied central viewer.

Multiple Hosts Monitoring High Traffic Networks

A packet broker load‑balances and recombines high‑rate traffic across many capture nodes.

Notes

Using a Network Packet Broker (NPB) allows traffic to be load balanced and recombined. This is especially useful in HA or asymmetric routing cases
By using a NPB, other security devices can see the same traffic arkime sees
When running multiple arkime-captures on the same host make sure the IO doesn’t overwhelm the disk and other subsystems.
Use a TAP with high traffic networks since many mirror ports drop traffic under heavy load
Operators use an apache fronted viewer (central viewer) and don’t hit the other viewers directly. The apache provides authentication.
Lock down ES and arkime viewer with iptables

Multiple Clusters

Independent clusters, each with its own capture nodes and ES, all reachable through the network; a virtual‑path reverse proxy routes operators to either one.

Notes

It is possible to use a single ES cluster using the prefix= ini configuration
Operator uses apache fronted viewers (central viewers) and doesn’t hit the other viewers directly. The apache provides authentication. Can use virtual paths to route to different clusters.
NPBs are recommended for high traffic networks

Packet Portal (Sensors behind NAT)

Experimental — added in Arkime 6.7.0.

Normally the Central Viewer opens short-lived outbound connections to each Sensor’s viewer to fetch pcap, run hunts, and proxy per-node requests — which only works when the Sensor is directly reachable. A Packet Portal flips that around for edge sensors that sit behind NAT, a firewall, or an IP‑locked reverse proxy: the Sensor opens one long-lived outbound connection to the Central Viewer, and the Central Viewer sends its normal node‑to‑node requests back down that same connection. When no portal is present everything falls back to normal node‑to‑node HTTP, so the feature is purely additive.

The Sensor's viewer dials out once, directly to the Central viewer; every request the Central Viewer sends back over that portal is individually server‑to‑server authenticated.

Notes

Use a packet portal when a Sensor’s viewer cannot be reached directly — a Sensor behind NAT or a firewall, or a Central Viewer that is fronted by a reverse proxy, uses header authentication, and is IP locked down.
On each Sensor, set packetPortalConnect to the Central Viewer(s) to keep an outbound portal open to. Portals reconnect automatically with backoff, and multiple Central Viewers can each reach the same Sensor.
On the Central Viewer, pick one way to accept portals: a dedicated packetPortalPort (recommended — its own firewall rules, unaffected by the main viewer’s proxy/header auth/IP restrictions), or packetPortalListen=true to accept them on the existing viewer port.
Every request carried over a portal is individually S2S authenticated with serverSecret, and the loopback address and any userNameHeader a request appears to carry are not trusted — so header/IP auth cannot be spoofed through a portal.
Because a Sensor names itself when it opens a portal, the Central Viewer authenticates that claim with the [packetportal-nodes] section (per‑node password and/or source IP, falling back to [esproxy-sensors]), so one compromised Sensor cannot claim another’s node name.
See the Packet Portal settings for the full list of options.

Decrypting TLS Traffic with PolarProxy

Arkime stores and indexes whatever packets it captures, but TLS‑encrypted sessions show up as opaque ciphertext. PolarProxy (from Netresec) is a transparent TLS‑inspection proxy that sits between your users and the servers they reach: it terminates and decrypts each TLS session, re‑encrypts it on to the real server, and streams a copy of the decrypted traffic to Arkime over PCAP‑over‑IP. Arkime then indexes the plaintext just like any other capture.

The user's HTTPS is transparently redirected through PolarProxy, which decrypts it and streams the plaintext to Arkime over PCAP‑over‑IP; the session is re‑encrypted on to the real server.

How it works:

Send client traffic through PolarProxy. Either transparently — a gateway iptables/ufw DNAT rule redirects outbound 443 to PolarProxy’s :10443 — or by pointing clients at it explicitly:
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to <polarproxy_host>:10443
Because PolarProxy is a MITM, clients must trust PolarProxy’s root CA or they will see certificate warnings.
Have PolarProxy stream decrypted packets to Arkime. Start PolarProxy with the PCAP‑over‑IP connect flag so it dials the Arkime host and sends a copy of everything it decrypts:
--pcapoveripconnect <arkime_host>:57012
Listen for the stream on Arkime. Set pcapReadMethod=pcap-over-ip-server in config.ini so capture accepts the PCAP‑over‑IP connection on TCP 57012 (the interface setting is ignored — set it to dummy).

For a full, worked walk‑through see Netresec’s Capturing Decrypted TLS Traffic with Arkime.

Remote Device Capture

In some cases, it’s not practical or possible to physically co-locate a capture server near a device we want to instrument — for example a small router or appliance that can see the traffic but can’t run a full Arkime install. There are two common ways to get that remote traffic to Arkime.

Option 1 — TZSP forwarding (recommended)

The remote device captures on one of its interfaces and forwards each packet, encapsulated in TZSP, over UDP to an Arkime capture process configured with pcapReadMethod=tzsp. Nothing is stored on the device, so this works well for small appliances and routers — Arkime even ships a tiny tzsp_forwarder helper for exactly this.

On the remote device, run the tzsp_forwarder helper (build it from contrib/tzsp_forwarder.c) pointed at the interface to monitor and the Arkime host:
./tzsp_forwarder br0 <arkime_host> [<bpf_filter>]
On the Arkime capture side, set pcapReadMethod=tzsp (the interface setting is ignored — set it to dummy) and capture will listen on tzspPort (UDP 37008).
For a full, worked end-to-end example — forwarding from a Ubiquiti UDR7 router into a Dockerized Arkime, plus optional HTTPS with Caddy — see Arkime on the UDR7.

Option 2 — SSH pcap streaming (not recommended)

If the device is reachable via ssh, we can log in to the remote device, start a capture, and stream the raw pcap back to an Arkime server through a UNIX pipe. One starts an Arkime capture process using the pipe as the capture interface, giving real-time capture of the remote device.

Steps:

Create named pipe on the local capture machine, you can name whatever you want:
mkfifo /tmp/10.1.2.3-ens3
Start capture on the local capture machine:
/opt/arkime/bin/capture --copy -r /tmp/10.1.2.3-ens3
Use ssh to copy the data from remote to localhost machine, exclude capturing the traffic we are sending over ssh:
ssh user@10.1.2.3 sudo /usr/sbin/tcpdump -s0 -i ens3 -w - not host 192.168.10.5 > /tmp/10.1.2.3-ens3
(The sudo and full path to tcpdump might not be required, remember to update the ips.)

This is NOT the recommended way to use Arkime.