Edge Configuration
The Configuration page (/edges/:id/config) is where you manage all aspects of an edge's network configuration. Navigate here by clicking Configure on the Edge Detail page.
Changes are not applied immediately. When you modify any configuration section, the changes are staged and the edge is marked as "dirty". Click Sync Config in the page header (next to Config History) to push the configuration to the edge directly from this page. See Syncing Configuration for details.
Configuration Tabs
The configuration page is organized into the following tabs:
Physical Interfaces
View and configure the hardware network ports on the edge:
- Port type — WAN or LAN role assignment
- MTU — Maximum transmission unit size
- Enabled/Disabled — Toggle individual ports
- Link state — Current up/down status
Physical interface configuration is typically set during provisioning via Config Templates and should only be modified with care.
Logical Interfaces
Manage the logical network interfaces built on top of physical ports. Click Add Logical Interface or the pencil icon on any row to open the interface modal.
Add / Edit Logical Interface modal
The modal is a single scrolling form — there are no tabs. Sections appear and disappear based on the selections you make:
Identity (always visible)
| Field | Description |
|---|---|
| Physical Interface(s) | The hardware port(s) to bind this logical interface to. For Role = WAN or Role = LAN with Type = Routed, a single-port dropdown is shown. For Role = LAN with Type = Bridged, a checkbox list lets you select one or more ports — see Bridged LAN (multi-port) below. Ports are listed in natural sort order (G0, G1 … G10). Disabled ports are labelled (disabled). |
| VLAN ID | Optional 802.1Q VLAN tag (1–4094). When set together with a physical interface the name field auto-populates (e.g., G0.100). Not available for multi-port bridged interfaces. |
| Interface Name | Display / system name. Required. Auto-generated when a VLAN ID is set. |
| Description | Free-text label. Optional. |
Role & Type (always visible)
| Field | Description |
|---|---|
| Role | WAN (uplink, Internet-facing) or LAN (local network). Controls which service sections appear below. |
| Type | Routed or Bridged. |
Selecting Role = WAN and Type = Bridged shows an inline red error and the Save button is disabled. This combination is also rejected server-side (HTTP 400). Change Type to Routed.
If you change an existing interface's role and it has incompatible subscriptions (DHCP pools on a WAN, or NAT / port forwarding rules on a LAN), an amber warning lists up to 5 affected subscriptions. You can still save — it is a soft warning — but you should review and remove the orphaned subscriptions from the sections below before confirming.
Bridged LAN (multi-port)
When Role = LAN and Type = Bridged, the Physical Interface field switches from a single-port dropdown to a checkbox list that lets you select one or more ports. All selected ports are attached to the same VPP bridge-domain alongside the BVI (bridge virtual interface, loop0), creating a single L2 broadcast domain. The edge acts as the gateway and DHCP server for all wired devices on any of those ports.
Helper text in the modal: "Select 1 or more ports. All selected ports will share the same L2 broadcast domain."
The Logical Interfaces table displays the member port names comma-joined when more than one is selected (e.g., G3, G4).
When to use multi-port bridging
| Scenario | Example |
|---|---|
| Small office without a switch | Plug LAN devices directly into G2, G3, and G4; all get DHCP from the edge and can reach each other via L2 forwarding without any additional hardware. |
| Physical cable redundancy | Span the same L2 broadcast domain across two or more ports so a cable failure on one port does not isolate a device. |
| Mixed-device LAN | A wired phone on G2 and a desktop on G3 share one DHCP scope and the same subnet gateway. |
Once the interface is saved and the config is synced, all wired clients on the member ports receive DHCP leases from the edge's DHCP server and can communicate with each other via L2 — no inter-VLAN routing required.
Bridged LAN interfaces do not support VLAN IDs, DHCP Client mode, or IPv4 Aliases — those fields are hidden when Type = Bridged is selected. A DHCP server pool must be added (in the DHCP Server Pools section below) for clients to receive addresses automatically.
Addressing (always visible)
- DHCP Client toggle — available when role = WAN, or role = LAN with Type = Routed. The toggle is hidden entirely when role = LAN and Type = Bridged (a bridged LAN cannot also be a DHCP client).
- When DHCP Client is enabled: the IPv4 address, subnet, and gateway fields are hidden (not just disabled). A blue info banner replaces them: "IPv4 address, subnet, and gateway will be auto-configured from the upstream DHCP server when this interface comes up."
- When DHCP Client is disabled: IPv4 address, subnet mask (dropdown, /8 – /30), and default gateway fields are shown.
IPv4 Aliases (visible only when Role = WAN and DHCP Client is disabled)
An alias is an additional IPv4 address on the same physical port. Use this when your ISP provides a block of addresses on a single uplink (for example, a /29 with six usable addresses).
- Click Add Alias to add an entry. Each alias requires an IP address and a subnet mask.
- Up to 16 aliases are supported per interface.
- Each alias becomes its own NAT pool entry and is eligible as a port-forwarding target (see Port Forwarding below).
- Aliases are not available when DHCP Client is enabled — static addressing is required.
Removing an alias that is referenced by an active port-forwarding rule will leave that rule without a valid external IP. Review and update any affected rules before saving.
DHCP Server Pools (visible only when Role = LAN)
Lists the DHCP pools allocated on this interface. Click Add DHCP Pool to create a new pool, or use the edit / delete icons on each row.
If you are creating a new interface this section shows "Save interface first, then add DHCP pools here." After the initial save the modal transitions to edit mode in place and the section unlocks — you do not need to close and re-open the modal.
Source NAT (visible only when Role = WAN and Type = Routed)
Lists source NAT rules for outbound masquerading on this interface. Click Add Source NAT to add a rule.
Port Forwarding (visible only when Role = WAN and Type = Routed)
Lists inbound DNAT / port-forward rules. Click Add Port Forward to add a rule.
When editing or creating a port-forwarding rule the form includes an External IP picker. This field lets you choose which IP address the rule listens on:
| Option | When to use |
|---|---|
| Primary IP | The interface's main IPv4 address (default) |
| Alias (one per alias) | An alias address configured in the IPv4 Aliases section above |
This means the same external port (e.g., TCP 8080) can be mapped to a different internal destination on each WAN, or to different aliases on the same WAN, without conflict.
Same "Save interface first" placeholder applies for Source NAT and Port Forwarding on new interfaces.
Advanced (collapsible, collapsed by default)
| Field | Description |
|---|---|
| MTU | Interface MTU in bytes (576–9000, default 1500) |
| MSS | TCP MSS clamping value (536–8960, default 1460) |
| VRF | Assign the interface to a Virtual Routing & Forwarding instance (see below) |
VRF (Virtual Routing & Forwarding)
Each logical interface can be placed in its own VRF. VRFs create independent routing tables in VPP, which is required when two WAN interfaces share the same subnet (for example, two ISP uplinks that both use 192.168.0.0/24). VPP rejects two interfaces with the same subnet in the same routing table but accepts them when they are in separate VRFs.
- VRF 0 is the default. If you do not assign a VRF the interface joins VRF 0.
- To assign a non-default VRF, select one from the dropdown. If no suitable VRF exists yet, click + New VRF inline to create one without leaving the modal.
- When an interface is in a non-zero VRF, its NAT pool, static routes, and ABF routing-policy rules are all scoped to that VRF automatically.
- VRFs are tenant-scoped. The numeric VRF Table ID maps directly to the VPP FIB instance.
Cross-VRF route leaking is not currently supported in the UI. Traffic originating in a non-default VRF can only reach destinations that are also in that VRF, plus any routes you add via static routes on the same VRF.
The Configuration Summary page (on the Edge Detail) shows the VRF assignment for each interface in an Advanced column so you can verify isolation at a glance without opening each interface.
Multi-WAN configuration
An edge supports multiple WAN-role logical interfaces simultaneously. Each WAN interface is fully independent:
- Carries its own Source NAT and port-forwarding rules
- Participates in service-chain (Suricata) inspection — traffic is steered through the IDS/IPS regardless of which WAN it enters or exits
- Participates in Dynamic Path Selection (DPS) — all WAN uplinks are eligible as DPS probe targets
- Static-IP WANs each emit their own default route automatically (previously only DHCP WANs generated a default route)
A common multi-WAN setup is two physical uplinks (G0 and G1) each configured as WAN, with different ISP addresses, in separate VRFs when the subnets overlap. Port-forwarding rules are bound to individual WAN IPs so the same external port can resolve differently on each uplink.
If your two ISPs both use the same private subnet (e.g., 192.168.0.0/24), assign each WAN logical interface to a different VRF using the Advanced section. VPP requires unique subnets within a single routing table but allows the same subnet across separate VRFs.
WAN Uplinks
Turns two or more WAN-role logical interfaces into a single managed uplink policy, so the edge can fail over or load balance between them on its own. Set the mode (Single / Failover / Load Balance), order uplinks by priority or weight, configure per-uplink health probes and quality thresholds, and review the failover history the edge has reported.
This is distinct from the multi-WAN configuration described above, which is about running independent WAN interfaces side by side. The policy is only applied to the edge when the mode is Failover or Load Balance and at least two usable uplinks resolve.
See WAN Uplinks for the full tab.
Subscriptions
The Subscriptions tab is a read-only summary of all DHCP pools, Source NAT rules, and port-forward rules across every logical interface on this edge.
Subscriptions are created and managed inside the Logical Interface modal (described above). You cannot add, edit, or delete subscriptions directly from the Subscriptions tab.
What the tab shows:
- A blue info banner directing you to the Logical Interfaces tab to make changes.
- Filter chips: All / DHCP Pools / NAT + Port Forwarding — narrow the list by type.
- Rows grouped by logical interface (collapsible). Each group header shows the interface name and a count of its subscriptions.
- Each group header has an "Edit in Logical Interfaces →" link that switches to the Logical Interfaces tab so you can open the owning interface and manage subscriptions there.
- Each row shows: Interface, Type (colour-coded badge), Name, Details (addresses / ports in compact form), Description, and Status (Enabled / Disabled).
Static Routes
The routing table for the edge. Each route entry contains:
| Field | Description |
|---|---|
| Destination Network | The target network in CIDR notation (e.g., 10.0.0.0/8) |
| Gateway | The next-hop IP address |
| Interface | The outgoing interface for this route |
| Metric | Route priority (lower values are preferred) |
Click Add Route to create a new static route. Existing routes can be edited or deleted.
ACL
Access Control Lists define traffic filtering rules for the edge. Rules are evaluated in priority order (lowest number first).
Each ACL rule contains:
| Field | Description |
|---|---|
| Priority | Numeric priority determining evaluation order (lower = first) |
| Action | Permit (allow) or Deny (block) |
| Source IP | Source IP address or CIDR range |
| Destination IP | Destination IP address or CIDR range |
| Protocol | IP protocol (TCP, UDP, ICMP, or Any) |
| Source Port | Source port or port range (TCP/UDP only) |
| Destination Port | Destination port or port range (TCP/UDP only) |
Policies
Configure routing policies and traffic classification rules. This tab (labelled "Policies" in the UI) shows:
- Edge policies — Policies applied directly to this edge (editable)
- Device Group policies — Policies inherited from Device Group Access Policy templates (read-only, collapsible section)
See Routing Policies for full details on rule configuration.
Gateways
Configure the edge's VPN gateway instances:
wg0 — IoT Gateway
The IoT Gateway provides a hub-spoke VPN topology for connecting IoT devices, connectors, and remote sites:
- Server Address — The WireGuard endpoint address (typically the edge's WAN IP)
- Listen Port — The UDP port WireGuard listens on
- MTU — Tunnel MTU setting
- Peers — List of authorized peers with their public keys and allowed IP ranges
wg1 — App VPN
The App VPN provides client-server remote access VPN for end users. Two protocols are supported:
| Protocol | Description |
|---|---|
| WireGuard | High-performance tunneling with Curve25519 key exchange. IP pool: 10.10.0.0/16 |
| IKEv2 | Standards-based IPSec with certificate authentication via StrongSwan. IP pool: 10.11.0.0/16 |
The protocol is configured on the App VPN server settings. When switching protocols, existing VPN client registrations must be re-provisioned.
- Listen Port — UDP port for VPN connections
- DNS — DNS servers pushed to connecting clients
- Allowed IPs — Network ranges accessible through the tunnel
VPN user peers are managed through the VPN Clients section and are automatically added to the wg1 configuration.
Flow Export (IPFIX)
IPFIX (IP Flow Information Export) enables the edge to collect and export network flow data:
- Enable/Disable — Toggle flow data collection
- Collector Address — The IP address and port of the flow collector
- Active Timer — How often active flows are exported
- Inactive Timer — Timeout for idle flow expiration
- Record Layers — L2, L3, and/or L4 data collection
Suricata IDS/IPS
Configure the Suricata intrusion detection and prevention system:
- Enable/Disable — Toggle Suricata on this edge
- Mode — IDS (detect only) or IPS (detect and block)
- Rule sets — Active detection rule categories
Suricata service chain configuration (ABF redirect through tap100/tap101) is managed automatically by the agent when Suricata is enabled. No separate UI tab is required.
SSH Access
Manage the reverse SSH tunnel and generate user certificates for remote CLI access:
- Tunnel Key — Generate or regenerate the tunnel keypair
- Tunnel Status — Active/inactive indicator (from edge metrics)
- Tunnel Controls — Start, stop, restart, health check (via MQTT)
- User Certificate — Generate a 24-hour SSH certificate for admin access
- Connection Command — Ready-to-paste SSH ProxyJump command
See SSH Access for the complete setup workflow.
Key Rotation
Manage WireGuard key rotation for the edge's tunnel instances:
- View current key age and rotation schedule
- Trigger manual key rotation
- View rotation history
Page Header Actions
The Configure page header contains two action buttons alongside the standard navigation controls:
| Button | Description |
|---|---|
| Sync Config | Push pending configuration changes to the edge. Color-coded: yellow (pending changes), red (sync failed), gray (synced). Available here so you can sync without leaving the Configure page. |
| Config History | View previous configuration snapshots. Each entry shows the timestamp, user who made the change, and a summary of what was modified. |