Key Concepts

This page defines the core terminology used throughout SecureLink. Understanding these concepts will help you navigate the platform and configure your network effectively.

Devices

Edge

A dedicated hardware appliance or virtual machine deployed at a customer site. Edges run VPP (Vector Packet Processing) for high-performance packet forwarding, supporting routing, firewalling, NAT, VPN tunnels, and traffic monitoring.

Edges operate in one of two modes:

• DPDK mode -- Uses the Data Plane Development Kit for direct hardware NIC access, bypassing the kernel network stack. This delivers the highest throughput (10 Gbps+) and is used on bare-metal deployments with compatible NICs.
• AF_PACKET mode -- Uses the Linux kernel's AF_PACKET interface to pass traffic to VPP. This does not require special NIC drivers and is suitable for virtual machines, cloud instances, and environments where DPDK is not available.

info

The mode an edge runs in is determined at deployment time and reported in the dashboard. Both modes provide the same feature set -- the difference is in how VPP accesses the physical network interfaces.

MTGE (Multi-Tenant Gateway Edge)

A shared gateway edge that serves multiple tenants from a single physical or virtual device. Each tenant on an MTGE receives fully isolated network resources through VRF technology, meaning one tenant's traffic and routing tables cannot interact with another's.

MTGEs are typically deployed at data centers or co-location facilities where multiple customer organizations need gateway services but dedicated hardware per tenant is not practical.

Key characteristics:

• Each tenant gets isolated WireGuard tunnels, routing, NAT, and ACL configurations
• Tenant onboarding and offboarding is managed through the dashboard
• Optional internet breakout can be enabled per tenant

Connector

A lightweight edge device that uses native Linux networking (no VPP). Connectors establish a WireGuard tunnel back to a designated hub edge, extending the SD-WAN fabric to small sites, branch offices, or cloud VPCs where a full edge deployment is not warranted.

Key characteristics:

• Minimal resource requirements (runs on standard Linux)
• Connects to a hub edge for upstream connectivity
• Supports static routes, NAT, and ACL rules
• Managed through the same dashboard as dedicated edges

Orchestrator

The central management platform -- this is the SecureLink web application you are using. The orchestrator:

• Pushes configuration to all device types (edges, MTGEs, connectors) via MQTT
• Collects telemetry, metrics, and logs from devices
• Provides the web dashboard for monitoring and management
• Manages user authentication and tenant isolation

How Components Interact

Understanding the high-level data flows helps you reason about what happens when you make changes in the dashboard and when devices report status.

The Configuration Path

When you make a configuration change in the dashboard, it flows through the system in six steps:

1. You edit — You change a setting in the Web UI (e.g., add a WireGuard peer, update a NAT rule)
2. API saves — The API writes your change to the database and marks the edge as having pending changes
3. You sync — You click Sync Now (or an automatic sync triggers), and the API builds a batch configuration containing all of the edge's settings
4. MQTT delivers — The batch is published to the edge's MQTT topic and delivered to the connected agent
5. Agent applies — The edge agent receives the batch and applies it to VPP (or Linux networking for connectors), following a strict dependency order
6. Edge confirms — The agent sends a confirmation back with a hash of the applied configuration, which the orchestrator verifies matches what it sent

This staged model means changes are never applied piecemeal — the edge always receives and applies a complete, consistent configuration.

The Monitoring Path

Edge devices continuously report their status back to the orchestrator through several channels:

• Heartbeats — Edges send periodic status messages (every 30--60 seconds depending on device type) that include interface statistics and the device's WAN IP. These keep the "Last Seen" timestamp current.
• Metrics — System measurements (CPU, memory, interface counters) are collected and stored in a time-series database for the performance charts on the dashboard.
• Logs — Container logs from edge services are collected and stored for troubleshooting via the monitoring dashboard.
• Flows — On edges with flow monitoring enabled, IPFIX traffic records are aggregated on the edge and pushed to the metrics database for traffic analysis.

For Admins

For a deeper look at how these components work together — including architecture diagrams, the full config sync pipeline, MQTT topics, and security architecture — see the Platform Architecture section in the Admin Guide.

Networking

Edge Peering

Site-to-site encrypted tunnels between edges using the WireGuard protocol. Edge peering allows traffic to flow directly between sites without routing through a central hub (in mesh topologies) or through a designated hub (in hub-spoke topologies).

SecureLink supports three peering topologies:

Topology	Description
Full Mesh	Every edge peers with every other edge in the group. Provides direct connectivity between all sites but scales quadratically with the number of members.
Hub-Spoke	One edge acts as the hub, and all other edges (spokes) connect only to the hub. Traffic between spokes routes through the hub. Simple and scalable.
Partial Mesh	Edges peer with a selected subset of other edges. Provides flexibility to create custom connectivity patterns where full mesh is excessive but hub-spoke is too restrictive.

Peering supports dual tunnels for redundancy:

• Active/Standby -- A secondary tunnel takes over automatically if the primary fails
• Active/Active -- Both tunnels carry traffic simultaneously for load distribution

VRF (Virtual Routing and Forwarding)

A network isolation technique that creates separate, independent routing tables on a single device. In SecureLink, VRFs are used on MTGEs to ensure that each tenant's traffic is completely isolated from other tenants sharing the same physical gateway.

tip

You do not need to manage VRFs directly. SecureLink automatically allocates and configures VRFs when tenants are assigned to an MTGE.

WireGuard

A modern, high-performance VPN protocol used throughout SecureLink for encrypted tunnels. Different WireGuard interfaces serve different purposes:

Interface	Purpose
wg0	IoT / device VPN tunnel (connecting connectors and IoT devices to hub edges)
wg1	Apps VPN tunnel (remote access for VPN client users)
wg2	Primary site-to-site peering tunnel between edges
wg3	Secondary site-to-site peering tunnel (used in dual-tunnel redundancy configurations)

ACL (Access Control List)

Firewall rules that control which traffic is permitted or denied through an edge device. ACLs are applied to interfaces and evaluated in order, with each rule specifying:

• Source and destination IP addresses or subnets
• Protocol (TCP, UDP, ICMP, or any)
• Port ranges
• Action (permit or deny)

warning

ACL rules are evaluated top-to-bottom. A packet is matched against the first rule that applies. Ensure your most specific rules are placed before broader rules.

NAT (Network Address Translation)

Translates private IP addresses on your internal network to a public IP address for internet access. SecureLink edges use NAT44-EI (Endpoint-Independent NAT) to provide outbound internet connectivity for devices behind the edge.

Batch Config

The mechanism SecureLink uses to push configuration changes from the orchestrator to edge devices. When you make changes in the dashboard (such as adding a WireGuard peer, modifying an ACL rule, or updating interface settings), those changes are collected into a batch and sent to the device via MQTT.

The batch config process:

1. You make configuration changes in the dashboard
2. Changes are staged as "pending"
3. You trigger a sync (or it happens automatically)
4. The orchestrator publishes the full configuration batch to the device via MQTT
5. The device applies the configuration and sends a confirmation back

Routing & Resilience

BGP (Border Gateway Protocol)

A dynamic routing protocol used in edge peering to exchange route information between sites. When edges are peered, BGP sessions are established over the WireGuard tunnels so that each site automatically learns the routes to reach other sites' networks.

BFD (Bidirectional Forwarding Detection)

A lightweight protocol that monitors the health of peering tunnels and detects failures in sub-second timeframes. When BFD detects a tunnel failure in a dual-tunnel configuration, it triggers automatic failover to the standby tunnel, minimizing downtime.

info

BGP and BFD are configured automatically when you set up edge peering. You do not need to manage these protocols directly unless you have advanced routing requirements.

Identity & Access

Tenant

An organization or customer account within SecureLink. Each tenant has:

• Isolated network resources (edges, connectors, VPN users, configurations)
• Separate user accounts and role assignments
• Independent monitoring data and logs
• Its own set of feature flags controlling which capabilities are available

All data in the SecureLink dashboard is scoped to your tenant. You will only see resources that belong to your organization.

User Types

Type	Role	Capabilities
SuperAdmin	Platform administrator	Full access across all tenants. Manages the platform itself.
Tenant Admin	Organization administrator	Full access within their tenant. Manages edges, users, and configuration.
VPN User	Remote access user	Connects to the network via VPN client applications. No dashboard access.

danger

SuperAdmin access provides unrestricted control over all tenants and platform configuration. This role should be limited to platform operators and never assigned to tenant-level users.

Further Reading

• First Login -- Access the dashboard and configure your profile
• Navigating the Dashboard -- Learn the dashboard layout and navigation patterns