Nexapp - Overview, Features, Limitations
High Availability (HA)
NexappOS High Availability (HA) provides redundancy through a two-node firewall cluster.
If the active firewall fails (hardware fault, software crash, or planned maintenance), the standby firewall automatically takes over networking and security services, minimizing downtime.
HA is designed for environments where uninterrupted connectivity is critical, such as:
- continuous internet access
- always-on VPN services
- security enforcement without gaps
Overview
An HA cluster consists of:
- Primary node – normally active, handles all traffic and services
- Secondary node – normally standby, ready to take over
- Virtual IPs (VIPs) – shared IPs per interface used by clients
Client best practice:
All clients must use the VIP as their gateway/DNS/VPN endpoint.
This ensures instant continuity after failover.
Key Concepts
Primary Node
The firewall that actively processes traffic and runs services.
Secondary (Backup) Node
The firewall that stays on standby and becomes active only if the primary fails.
Virtual IP (VIP)
A floating/shared IP per participating interface.
VIPs let hosts keep the same gateway and service endpoints across failover.
HA Roles
Master
- The node currently active
- Interfaces are up and forwarding traffic
- Normal role for the Primary node
Backup
- The node currently standby
- Does not forward traffic
- Normal role for the Secondary node
How HA Works
Heartbeat (VRRP)
Both nodes continuously check each other using VRRP over a dedicated LAN physical link called the HA interface.
If the master stops responding, the backup immediately assumes ownership of VIPs and becomes master.
Settings Synchronization
The Primary node securely replicates its configuration to the Secondary node, including runtime state such as:
- VPN objects
- routes
- active sessions metadata
Role-based Service Behavior
HA automatically enables/disables services based on node role:
Secondary receives updates but stays “quiet”
It stores full configuration but keeps most services off (VPNs, remote backups, update checks, reporting, etc.) to prevent duplication and conflicts.Node becomes Master
It enables all required services and starts handling forwarding, VPNs, routing, and security.Node becomes Backup
It disables most services and stops forwarding traffic while still tracking sync changes.
Supported Features (Synchronized)
HA synchronizes most NexappOS capabilities, including:
- Firewall rules, port forwards, DHCP, DNS
- VPNs: OpenVPN, IPsec, WireGuard
- QoS, MultiWAN, DPI rules
- Reverse proxy and ACME certificates
- Static routes
- Netifyd configuration
- InstaShield IP (banip)
- InstaShield DNS (adblock)
- Users and firewall objects
- Netmap
- SNMP server (snmpd)
- NAT helpers
- Dynamic DNS (ddns)
- SMTP client (msmtp)
- Backup encryption password
- Controller connection and subscription (ns-plug)
- Active connections tracking (conntrackd)
- Hotspot (dedalo) only on physical interfaces
WAN Interface Types and Supported Setups
HA supports the following interface configurations:
- Static IPv4 and static IPv6
- IPv4 via DHCP
- Physical Ethernet interfaces
- Bonded interfaces (link aggregation) made of physical NICs
- Bridge interfaces over physical NICs
- VLANs on physical, bond, or bridge interfaces
- PPPoE on physical or VLAN interfaces
Limitations
Interface Limitations
- Only IPv4 is supported on LAN interfaces in HA
- The HA interface must be physical
- Bonds/bridges are supported only for additional LAN/WAN interfaces, not for the HA interface
- Hotspot is supported only on physical interfaces
General Limitations
- Extra packages not included in the firmware image are not supported in HA
(examples: NUT, etherwake, third-party daemons) - rsyslog configuration is not synchronized
If you need centralized logging, use the Controller instead. - After first sync, the Secondary node adopts the same hostname as the Primary.
The UI still shows the shared hostname, but role is visible in the dashboard.
SSH prompts also show node role to avoid confusion.