PDF

NetCrunch Connections

Learn how clients and remote components connect to the NetCrunch Server — locally, through HTTPS, or via the NetCrunch Connection Cloud (NCC). Understand supported protocols, security levels, and available connection types.

Accessing NetCrunch

NetCrunch supports various connection types to enable access from consoles, browsers, remote probes, and external systems. Depending on your environment, you can use direct TCP, HTTPS, or NCC to securely connect.

Clients

NetCrunch allows connections from several types of clients:

  • Desktop Console
  • Web Console (Browser)
  • Monitoring Probes
  • API Clients & Webhooks

Administration Console (Desktop)

The NetCrunch Administration Console is the most powerful and optimized client, designed for fast, real-time interaction. It caches a large amount of data locally and synchronizes only the changes with the server, providing high responsiveness and reduced load.

It supports fine-grained access control, so it is no longer limited to administrators. Users with proper access rights can perform limited administration tasks — such as managing specific nodes or views — without requiring full administrative privileges.

Supported Systems

  • Windows 8 or newer (recommended: Windows 11)
  • Supports multi-monitor and touch devices

Connection Methods

  • Encrypted TCP – Use server address or name (port 12009)
  • Secure WebSocket (HTTPS) – Connect via Web Server (wss://your-server)
  • NCC (Cloud) – Use license ID (e.g., YZ-123-456) as the connection key

Features Exclusive to the Admin Console

  • Configure monitors, sensors, and monitoring packs
  • Manage alerting policies and response actions
  • Edit node properties and apply monitoring roles
  • View full alert and event history
  • Use diagnostic tools: Logs, SNMP Tools, Perfmon Explorer
  • Import/export configuration templates
  • Access Object Explorer and MIB Browser
  • Manage NetCrunch modules and task schedules
  • Delegate limited admin permissions per view or node
  • Faster performance than the Web Console due to local caching

Web Console (Browser)

The Web Console provides access through modern HTML5 browsers and is ideal for remote visibility and lightweight tasks.

Features

  • View and edit Graphical Views
  • Browse Atlas Tree, Events, and Reports
  • Role-based access per user or group
  • Excellent for executives or helpdesk roles

Supported Browsers

  • Edge 86+, Safari 15.4+, Chrome 86+, Firefox 86+, Opera
  • Internet Explorer is not supported

auto-reconnection

Staying Signed In

Selecting Remember me at sign-in makes the session persistent. Closing the browser no longer ends it — reopening the Web Console restores the previous session directly, in the same way a page reload does, without asking you to sign in again.

The session is held by a key stored in the browser, and the key rotates: each time a session is restored, the old key is spent and a new one issued. A key that has been used cannot be used a second time.

The stored key is discarded when you sign out explicitly, or when you clear it from the interface.

Because the session survives closing the browser, signing out matters on a shared or public machine. Simply closing the window leaves the session restorable by whoever opens the browser next.

Monitoring Probe

The NetCrunch Probe is a remote monitoring engine designed to operate behind NAT/firewalls in branch offices or customer sites.

Connection Methods

  • TCP (12009) – Standard encrypted connection to the server
  • NCC Cloud – Simplest and most secure method

Sending Data to NetCrunch

External data can be pushed into NetCrunch through:

  • Webhooks for status and event injection
  • REST API for metrics and status objects
  • Data Parsers for log or file-based input

Security & Protocols

NetCrunch supports multiple access paths. Each has a different level of security and use case:

Direct TCP (Encrypted on Port 12009)

  • Security: High
  • Encrypted connection using X25519 key exchange, AES-256-GCM encryption, and mutual PSK authentication
  • Provides TLS-level security with FIPS 140-3–compatible cryptography, without requiring certificates
  • Used by the Desktop Console and Probes to connect to the NetCrunch server

While port 12009 can be exposed to the Internet, we recommend placing the server behind a reverse proxy such as NGINX to provide an additional layer of protection against network-based attacks and unauthorized access attempts.

HTTP

  • Security: Low
  • Unencrypted, not suitable for production

HTTPS (Self-Signed)

  • Security: Medium
  • Encrypted, browser warnings expected

HTTPS (Valid Certificate)

  • Security: High
  • Full encryption + certificate validation
  • Required for secure WebSocket (wss://)

NetCrunch Connection Cloud (NCC)

  • Security: High
  • Requires no port forwarding or NAT traversal
  • Works via outbound HTTPS (port 443)
  • Supports:
    • Desktop Console
    • Web Console
    • Remote Probes

Use @<license-id> as the server address when connecting (e.g., @YZ-123-456).

Communication Scenarios

The following diagram summarizes the three common deployment scenarios:

  • Local Deployment (LAN) – Direct TCP & HTTPS
  • HTTPS-Only Deployment – For DMZ or simplified security models
  • Cloud Relay (NCC) – No inbound traffic needed

NetCrunch Connections Diagram created using NetCrunch Graphical Views.

Deployment Considerations

  • In HTTPS-only mode, all connections to the server are inbound and encrypted. This typically requires firewall rules or a reverse proxy (e.g., NGINX, HAProxy) in front of the NetCrunch server to properly route and secure access.
  • In Cloud Relay (NCC) mode, the server initiates a single outbound HTTPS connection (port 443) to the NCC relay. No inbound connectivity is required.
    This architecture is highly resilient and an ideal solution for zero-trust environments, where inbound ports are blocked, and all communication must be explicitly initiated and authenticated.

Related Topics

auto reconnectioncertificatecloudconnectionconsoledata receiverhttpremember mesessionweb