Starting from version 7.x, SafeLine WAF introduces a new feature: configuration synchronization. This allows a primary node to push configuration updates to one or more secondary nodes, enabling a true active-active deployment model for the WAF layer.
This post documents a basic functionality test using version 7.1.1-lts. For exact setup details, refer to the official configuration sync documentation.
Setup Overview
Configuration sync is easy to enable and requires no changes to your infrastructure. As long as:
- Secondary nodes can access the primary node,
- The license and version are identical between nodes,
...you're good to go.
In our test setup:
- Primary Node: A SafeLine instance (amd64) deployed in Place A
- Secondary Node: A SafeLine instance (arm64) deployed in Place B
How Config Sync Works
Once a secondary node is registered with the primary, it becomes read-only. Any existing configuration on the secondary will be overwritten by the primary.
Interestingly, in the current UI, the config fields on the secondary node remain editable, and only fail at the time of submission. A clearer UX would be beneficial — for example, collapsing all editable config sections on secondary nodes and displaying the sync status more prominently in the UI could help reduce misconfigurations.
Sync scope includes all management-side configurations, excluding:
- Custom config files manually added to the system
- Logs and traffic statistics
These remain local to each node. If you want to view logs or request stats, you’ll need to log into each node directly.
Note: The admin password from the primary node is also synced. So logging into a secondary requires the same credentials as the primary.
Sync Interval & Latency
- Sync is initiated by the secondary node, not pushed from the primary.
- By default, sync occurs every 60 seconds.
- This means config changes made on the primary are typically reflected on secondaries within a minute.
No bidirectional network is required — as long as the secondary can reach the primary, everything works.
This one-way, loosely coupled model naturally supports an active-active architecture. You can use techniques like GSLB or DNS-based traffic distribution to balance requests across all WAF nodes.
Fault Scenarios
We tested a few failure modes to understand how SafeLine behaves:
1. Primary Unreachable
We simulated this by shutting down the SafeLine service on the primary node.
- Secondary entered "unsynced" state.
- UI remained editable, but config changes still couldn't be saved.
- The "last sync time" stopped updating. Note: The secondary's perception of NGINX status on the primary may need further optimization.
2. Primary Recovery
Once the primary came back online, the secondary successfully re-synced during the next scheduled interval.
3. Secondary Failure
When the secondary went offline:
- The primary displayed its status as "unreachable"
- Sync status became "unsynced"
- Editing on the primary remained unaffected
4. Secondary Recovery
Once back online, the secondary reconnected and resumed config syncing automatically on the next cycle.
5. Node Removal
If the primary removes a secondary node from its list, that node detaches itself on the next sync attempt and reverts to an independent standalone WAF.
Final Thoughts
SafeLine’s config sync feature brings a lightweight, architecture-agnostic way to manage multi-region, multi-instance WAF clusters. With no shared storage or tight coupling required, it provides:
- Easy failover and high availability
- Consistent security posture across regions
- True active-active deployment, ready for DNS-based traffic distribution
Still, there’s room for UI polish — especially to make the master/secondary relationship more visible and reduce accidental config edits on read-only nodes.
If you're running SafeLine WAF in production, this feature is definitely worth exploring.
Top comments (0)