Your software in your customers' networks

Your product has a piece that runs at the customer's site: a sensor, a collector, a gateway or an agent. It has to reach your cloud, and sometimes your cloud or your support engineers have to reach it. This page shows what that usually takes, the same fleet on nfltr, measured, and where nfltr does not help.

The problem

Vendors with a component inside customer networks tend to fall into a few shapes. We read the public deployment, firewall and network-requirements guides of a dozen such vendors; these are the shapes they describe:

• An OT or industrial security sensor vendor. A sensor sits in a plant's network and sends what it sees to the vendor's cloud console. The plant lets it out only through a proxy in its DMZ. Operators also need the sensor's web UI or a shell, and the vendor needs a remote-support path into the plant.
• A network or infrastructure monitoring vendor. A collector runs as a VM at each customer and keeps one TLS connection to the vendor's cloud. The customer's firewall team is handed a list of wildcard cloud domains or IP ranges that change, and an exemption from TLS inspection.
• An industrial IoT gateway maker. Gateways sit behind the customer's NAT or on a cellular link, push telemetry, and the vendor's engineers need remote access to the machines behind them, usually through a VPN server or a cloud service the vendor runs for that alone.

Across these shapes, the data path to the cloud is already outbound only; nobody asks a customer to open an inbound port for telemetry. What each vendor builds and runs on top of it is:

• The client side, in every language and platform it ships: TLS with its own CA or pinned certificates, HTTP proxy support with authentication, keepalives that survive NATs, reconnect with backoff, certificate rotation.
• The cloud side: public endpoints, load balancers and DNS names per region, a CA and its renewals, published IP ranges kept stable for customers' allow-lists.
• The way back in: reaching one component by name for a command, a support session or the device's UI. This is often a second product with its own tunnels or VPN servers.
• Every customer's firewall ticket: the allow-list, the proxy settings, the TLS-inspection exemption, and the back-and-forth whenever an endpoint changes.

The demo: one fleet, before and after

The fleet is a control plane and three edge agents in .NET 8 with gRPC, written twice. It is an example in nfltr's own repository, which is not public, and an end-to-end test runs both versions in containers and checks every claim below by exit codes.

• Before, as such fleets are usually built: the control plane listens on a public TLS port under a DNS name, with a certificate from the fleet's private CA. Agents trust that CA, check the name, keep the connection alive through NATs, and keep one session open: commands go down it, progress and results come up.
• After, on nfltr's connect sidecar: every program listens on loopback only. One nfltr up beside each program connects out to the relay. The agent's session goes to a local socket, and the control plane can also call one chosen agent by name (edge-1/execute), which it could not do before: nothing reaches an agent behind NAT.
• One agent is at a customer site whose only way out is the site's HTTP proxy, in both versions. The proxy allows CONNECT to a short list of addresses and refuses everything else. That is the most common setup in the guides we read.

What the fleet's machines need, read from the test's runs:

What the customer's network team is asked

Before, each vendor hands each customer its own list: its endpoints, regions and ports, often wildcard domains or IP ranges that change. On nfltr, the list is the same for every customer and every vendor using it: allow outbound CONNECT (or plain outbound TCP) to grpc.nfltr.xyz:443 and nfltr.xyz:443. No inbound rule, at the customer or at the vendor.

• Through the site's proxy. nfltr up finds the proxy in HTTPS_PROXY (with NO_PROXY), as most tools do, and sends its credentials when the proxy URL carries them (http://user:password@proxy:3128). Both the agent's connection and the sessions it opens go through the proxy.
• TLS inspection. A proxy that intercepts TLS breaks any pinned connection, nfltr's included, unless the two names are exempt, which is the same exemption such guides already ask for. With end-to-end encryption on, an intercepting proxy sees only the inner TLS records either way.

Faults and restarts

The application keeps its own deadlines, cancellation and retries; the sidecar does not hide failures. A session the sidecar loses is closed on the local socket, so gRPC sees UNAVAILABLE at once and the application's retry runs.

Times are from the kill, with Docker restarting the container. A 1 s deadline on a 5 s command was cancelled on every agent, before and after, on both shapes. Progress updates arrived as the agent sent them: the first 102 to 123 ms after the call for 100 ms of work, before and after.

Migration effort

The protocol and the business logic did not change. A channel's target became a local endpoint of the sidecar, the listeners moved to loopback, and the TLS client code went:

Code lines exclude comments and blank lines. The removed lines are the TLS client: trust of the private CA, the server-name check, keepalives, the connect timeout and the proxy's CONNECT. The protocol and the business logic are untouched; the test applies the patch to the before tree, builds the after fleet from the result and checks that every command's outcome, progress and output are the same.

Rollout can be per agent: both paths run side by side, configuration picks one, and setting the old value back rolls an agent back. A call on an open session cost 0.06 to 0.21 ms more at the median on one host (two sidecars and the relay, end-to-end encryption on, against the direct TLS connection); on a real network each hop adds its round trip to the relay.

The relay never sees your traffic

With e2ee: true on a service, the two sidecars run TLS 1.3 inside the session, and the client accepts only the certificate whose SHA-256 it was given (the pin). There is no CA: provisioning makes a self-signed certificate per machine and records its pin in your inventory. The test checks that a wrong pin fails closed (nfltr dial exits 7, nothing delivered) and that a plain open of an encrypted service is refused (exit 4).

The relay still sees which agent talks to which service, when, and how many bytes, and it can refuse or cut a session. It cannot read or change what is inside.

Where nfltr is not a fit

• Your component only sends data out, and that works. If nothing ever has to reach the component, and your telemetry already flows out through the customer's proxy, nfltr replaces a working path and adds a hop. A latency-sensitive data plane, such as DNS answered on site, should not go through a relay at all.
• Per-customer isolation is enforced by the relay only per account. The relay authenticates the account key, not the component: a key on one customer's appliance reaches every service of the account. Keep your application's own per-component credential and check it, or use one account per customer.
• One name is one agent. edge-1/execute reaches exactly one machine. A service balanced across several machines needs a balancer behind one agent.
• TCP only. The sidecar carries byte streams; UDP protocols need their own path.
• The relay is on the path. Its availability is now part of yours; with your own relay it is yours to run.
• Air-gapped sites. Without any outbound path, no relay helps.

What it costs

A comparison of both sides at the same workload (agents connected around the clock, bytes per command and per session) will be here once prices are set. What nfltr will meter is on the pricing page: connected time per agent and bytes per kind of traffic. On the build side, the lines to count are the ones in the problem: engineering for the client and the way back in, the public endpoints and their certificates, and each customer's firewall work.

Is it for you?

Fits if your component sits behind customers' NATs and proxies, and your cloud or your support engineers need to reach one component by name, or you are about to build that path and the client-side connection code in more than one language.

Not for a component that only sends data out over a path that already works, a latency-critical data plane, or sites with no outbound connection.

Try it

On the vendor's side, the control plane publishes its service and maps each agent's:

# controlplane.yaml: nfltr up -c controlplane.yaml --api-key-file <key file>
agent: controlplane
services:
  fleet: { tcp: 5000, e2ee: true }
connect:
  edge-1: { target: edge-1/execute, listen: "127.0.0.1:7001", pin: "<edge-1's pin>" }

At the customer's site, beside your component:

# edge-1.yaml: HTTPS_PROXY=http://proxy.customer.example:3128 nfltr up -c edge-1.yaml --api-key-file <key file>
agent: edge-1
services:
  execute: { tcp: 50051, e2ee: true }
connect:
  fleet: { target: controlplane/fleet, listen: "unix:/run/nfltr/fleet.sock", pin: "<the control plane's pin>" }

Your component then talks to unix:/run/nfltr/fleet.sock instead of a host on the network, and your control plane calls 127.0.0.1:7001 to reach edge-1. Services and remote clients and the migration story have the details: pins, status, metrics, who runs the sidecar, and a gradual rollout.