Network requirements
Outbound
Section titled “Outbound”| Purpose | Destination | Port | When |
|---|---|---|---|
| Registration | bootstrap.<region>.nextpki.com |
9090/TCP | Once, at install |
| Reporting | ingest.<region>.nextpki.com |
9092/TCP, mTLS | Every scan cycle |
Both are outbound only. No inbound connection to the sensor is ever required - do not open a port for it. The local health endpoint binds to loopback by default and should stay there.
Inbound to scanned hosts
Section titled “Inbound to scanned hosts”The sensor connects to the ports you configured on the targets you configured. From the target’s point of view this looks like an ordinary TLS client that disconnects after the handshake.
If your network has intrusion detection, tell it about the sensor before the
first sweep. A host opening TLS connections across a whole subnet is exactly the
pattern IDS rules are written for, and conservative still means 16 concurrent
connections.
Segments with no route outbound
Section titled “Segments with no route outbound”You do not need to grant every sensor host its own internet access. A sensor can report through an internal relay that forwards on its behalf, so only the relay needs egress.
This is designed but not yet implemented - proxy_endpoint exists in the
data model and is not populated. If this is blocking a deployment, say so; it
moves up the roadmap on the strength of real demand rather than speculation.
Until then, options that work today:
- Put the sensor on a host that does have egress and let it scan the segment across the routed boundary.
- Allow egress from the sensor hosts to the two destinations above only, which is a narrow rule: two names, two ports, outbound, mTLS-authenticated.
Verifying what leaves
Section titled “Verifying what leaves”Because the source is published, you do not have to take the above on trust. The
gRPC client is a single file, and the report structure is defined in the .proto
files in the same repository. See data it sends.