Connector Configuration
Connectors are configured through the same batch configuration mechanism used by dedicated edges. Changes are staged in the orchestrator and pushed to the connector via MQTT.
Accessing Configuration
- Navigate to Equipment > Connectors.
- Click on a connector to open its detail page.
- Click Configure to navigate to the configuration page.
Detail Page
The connector detail page has two tabs:
Overview
Displays device information and network configuration:
- Device Information — Name, serial number, model, firmware, deployment region, registration and last seen timestamps
- Network — WAN IP, hub edge assignment (editable inline), WireGuard public key, listen port. When connected to an MTGE, also shows App VPN routes (connector LAN subnets injected into the MTGE tenant's wg1 allowed IPs)
- Config State — Sync status badge, sequence number, last push/ack timestamps, dirty flag with reason, and error details if the last sync failed
Tunnel Status
Displays the WireGuard backbone tunnel health:
| Field | Description |
|---|---|
| Interface | Tunnel interface name |
| Status | Active, down, or pending |
| Listen Port | WireGuard listen port |
| Public Key | Connector's public key |
| Server Address | Hub edge endpoint |
| MTU | Tunnel MTU |
| Endpoint Host | Resolved endpoint address |
| Enabled | Whether the tunnel is enabled |
Tunnel status is published every 60 seconds. A tunnel is considered active when a valid handshake has occurred within the last 3 minutes. If no handshake is detected, the status changes to down.
Configuration Sections
Connector configuration is organized into the following sections:
WireGuard
The WireGuard section manages the backbone tunnel to the hub edge.
| Field | Description |
|---|---|
| Public Key | The connector's WireGuard public key (auto-generated) |
| Endpoint | The hub edge's WireGuard endpoint address and port |
| Allowed IPs | Subnets routed through the tunnel |
| Keepalive Interval | Persistent keepalive interval in seconds |
The WireGuard tunnel is automatically configured when the connector is assigned to a hub edge. Manual changes to this section are rarely needed.
Static Routes
Static routes define how the connector forwards traffic to specific destination networks.
| Field | Description |
|---|---|
| Destination | The target network in CIDR notation (e.g., 10.0.0.0/8) |
| Gateway | The next-hop IP address |
| Interface | The network interface to use for this route |
To add a route, click Add Route, fill in the fields, and save. Routes are applied to the Linux routing table on the connector.
NAT
NAT rules provide source address translation using iptables, typically used to allow connector-side devices to reach the internet or other networks.
Common configurations include:
- Source NAT (masquerade) for internet-bound traffic
- SNAT with a specific source address for policy-based routing
ACL
Access Control List rules define iptables firewall policies to control traffic flow through the connector.
Rules can be configured with:
- Direction — inbound or outbound
- Action — accept or drop
- Protocol — TCP, UDP, ICMP, or any
- Source/Destination — network addresses and port ranges
Rules are evaluated in order. Place more specific rules above general ones.
E2E Peering Configuration
When a connector is added as a member of an Edge Peering group, peering configuration is managed through the peering UI — not on this page. The connector supports:
- WireGuard peering (default) — Uses
wg1for E2E tunnels - IPSec peering — Uses xfrm interfaces with pre-distributed SA keys (no IKE daemon needed)
When switching between WireGuard and IPSec peering protocols, the connector agent automatically cleans up the previous protocol's interfaces and configuration.
Configuration Sync
When you make changes to any configuration section:
- Changes are saved to the orchestrator database.
- The connector is marked as "dirty" (out of sync) with the reason shown on the detail page.
- A batch configuration payload is published to the connector via MQTT.
- The connector applies the configuration and sends a confirmation.
- The dirty flag is cleared upon successful confirmation.
Connectors use Linux native networking (WireGuard CLI, iptables, ip route) instead of VPP. This provides the same core functionality with a simpler setup, making connectors well suited for smaller sites. The trade-off is lower maximum throughput compared to VPP-based dedicated edges.