Firewall & connectivity

This page answers one question: which firewall rules do I need to open for LinkMesh to work?

There are two kinds of traffic, and they’re worth keeping straight because they have different shapes:

• Control plane — everything that talks to the LinkMesh server. The operator’s browser, your collectors (config pull + status), and the optional onboarding agent. All of it is HTTPS on 443, all of it reaches in to the server.
• Data plane — your collectors sending telemetry to your observability backends. This leaves your network outbound, on each backend’s own port, and never passes through LinkMesh.

The control plane (cyan, dashed) reaches the LinkMesh server on 443; the data plane (blue, solid) is your collectors sending telemetry outbound to your backends. Telemetry never transits LinkMesh.

Control plane — to the LinkMesh server

Every control connection is HTTPS on 443, inbound to the server. There is no inbound connection to a collector or to the agent — they always reach out to the server, so a managed host needs no open listening ports for LinkMesh.

Connection	Port	Protocol	Direction	Purpose	Required
Operator browser → server	443	HTTPS	→ server	Web UI + REST API	Yes
otelcol collector → server	443	HTTPS (OpAMP, WSS)	→ server	Config pull + health/status	Yes, for OpAMP collectors
Grafana Alloy collector → server	443	HTTPS (remotecfg)	→ server	Config pull	Yes, for Alloy collectors
Collector → server	443	HTTPS (OTLP)	→ server	Collector own-metrics (self-telemetry)	Optional
Onboarding agent → server	443	HTTPS (WSS, /v1/agent)	→ server	Discovery control channel	Optional — only if you run the agent

Binary OTLP through a WAF

The collector own-metrics path sends binary protobuf over HTTPS. If your server is behind an nginx-ingress with ModSecurity / the OWASP Core Rule Set in blocking mode, those POSTs are rejected with a 403 before they reach the app — a 403 with an nginx error page (rather than LinkMesh’s 401) is the tell. Exempt the OTLP own-metrics path from ModSecurity on that ingress.

Data plane — telemetry egress

Telemetry flows collector → backend, outbound from your network, on each backend’s own port. LinkMesh is not in this path; it never sees your telemetry. Open whatever your chosen backends need:

Connection	Port	Protocol	Direction	Purpose	Required
Collector → Grafana Cloud	443	HTTPS / OTLP	outbound →	Telemetry export	As configured
Collector → Loki / Tempo	backend port (usually 443)	HTTPS / OTLP	outbound →	Logs / traces export	As configured
Collector → Prometheus	backend port (usually 443)	HTTPS remote-write	outbound →	Metrics export	As configured
Collector → Kafka	broker port (e.g. 9092)	Kafka	outbound →	Telemetry export	As configured

The exact ports depend entirely on the destinations you configure — see your backend’s documentation for its ingest endpoint and port.

Optional: server → remote Git

A highly-available deployment keeps its config in a remote Git repository so multiple server replicas share one source of truth. When you use that storage backend, the server needs outbound access to the Git host:

Connection	Port	Protocol	Direction	Purpose	Required
Server → remote Git	443 (HTTPS) or 22 (SSH)	HTTPS / SSH	outbound →	HA config store	Only for the remote-Git backend

A single-instance server with the built-in store needs none of this.

At a glance

• Open to the server, on 443: the operator’s browser and your collectors (and the agent, if you use it). That’s the whole control plane.
• Open outbound from your network: collectors to your backends, on the backends’ ports.
• Nothing to open inbound to a collector or agent — they connect out.
• Telemetry never transits LinkMesh — it goes straight from your collectors to your backends.

See also

• How the edge talks to the server — the three control channels behind those 443 rules, side by side.
• Security & encryption — why every connection is outbound Bearer-over-TLS and nothing listens inbound on a managed host.