Collectors & Source IPs

Collectors receive syslog (514/udp) and SNMP traps (162/udp). The packet’s source IP identifies the sending device — but whether the collector sees the real source depends on how it’s run, because Docker’s bridge networking rewrites (NATs) the source to the docker gateway.

Deployment modes

Collector deployment	Real source IP?	Notes
Linux host, --network host	✅ Yes	Recommended for production.
Kubernetes	✅ Yes	hostNetwork: true on the collector pod/DaemonSet, or a Service with externalTrafficPolicy: Local.
Native desktop app (macOS / Windows)	✅ Yes	Runs the collector directly on the OS network stack. Best for small deployments. macOS .dmg · Windows .msi
Docker bridge (-p 514:514/udp)	⚠️ No	Source NAT’d to the docker gateway. Use host networking instead on Linux.
Docker Desktop (macOS / Windows)	⚠️ No	The container runs in a VM; all inbound is NAT’d. Host networking does NOT help here — it joins the VM’s network, not your machine.

Run with host networking on Linux

On Linux, run the collector with host networking so its sockets see the true sender:

docker run -d --name gridnms-collector --restart unless-stopped \
  --network host \
  -e GRIDNMS_TUNNEL_URL="https://<your-control-plane>/api/tunnel/ws" \
  -e GRIDNMS_STATE_DIR=/var/lib/gridnms \
  -v gridnms-collector-state:/var/lib/gridnms \
  gridnms/collector:latest-<arch>

Source masked? Attribution still works.

GridNMS extracts the sender’s host from the log itself — the syslog HOSTNAME field, CEF dvchost, or a JSON hostname — and stores it as Sender Host. Events are attributed to a device by that host (which survives NAT and relays, unlike the packet IP), are searchable on the Events page even before the device is onboarded, and unmanaged senders surface under Reports → Unmanaged Senders for one-click onboarding.

Developing on a Mac/Windows laptop?

The Docker Desktop NAT means test syslog shows the docker gateway as the source. That’s expected and dev-only — production collectors on Linux/Kubernetes preserve the real IP, and the native desktop app does the same for small on-prem deployments.

The network permission boundary

A collector may only initiate outbound connections to:

1. IPs/CIDRs within its explicitly assigned networks (assigned in Admin → Collectors),
2. the control plane (tunnel server) — always allowed, and
3. configured external storage endpoints (metric/log sinks).

The network assignment — not device assignment — is the permission boundary. Assigning a device to a collector is a routing convenience; the assigned networks decide what a collector is allowed to reach.