How-to: Manage NetWall HA Cluster with a Single Public IP Address

Applies To:

• This How-to applies to cOS Core version 12.00 and later. Older versions should work as well, but this has not been tested.
• High Availability (HA) Clusters
• DHCP-client in high availability for external HA shared IP address (version 15.00)

Objective

This article outlines a simplified method to configure an existing High Availability (HA) cluster that utilizes only one public IPv4 address, while still allowing management access to the active firewall from the internet. This approach streamlines the configuration process.

Scenario

In many deployments, it is desirable to conserve public IP addresses. This guide demonstrates how to manage an HA cluster using only one public IP, directing management traffic (HTTPS) to whichever firewall node is currently active.

Solution

The core of this solution lies in using a special type of address object, the HA4 IP address object, in an IP Policy rule to dynamically allow traffic to the shared public IP address and translate it to the private IP address of the active cluster node.

Configuration Steps

1. Disable "WebUI Before Rules":
   • Navigate to System → Device → Remote Management → Advanced Settings
   • Uncheck "WebUI Before Rules".
   • This step is necessary because we will be creating a manual IP Policy rule to handle management traffic. When "WebUI Before Rules" is enabled, cOS Core automatically creates hidden rules for management access, which would conflict with our custom rule.
2. Create an IP Policy Rule for Management Traffic:
   • Go to Policies → Firewalling → Main IP Rules
   • Click "Add" → "IP Policy" to create a new rule.
   • Configure the rule as follows:
     • Name: IP-policyREMOTEHTTP (or a descriptive name of your choice)
     • Action: Allow
     • Source Interface: wan1 (or your external interface)
     • Source Network: remote-managment-src-IP  (or a specific source if you wish to restrict management access, or all-nets for access from anywhere. )
     • Destination Interface: core
     • Destination Network: <Your_Shared_Public_IP_Object> (This is the single public IP used by your HA cluster. Create an address object for it if you haven't already)
     • Service: https
     • Advanced Filter
       • Geolocation: Source and Destination (Anywhere)
       • Schedule: (Anytime)
       • Application Filter: OFF
       • Application-based Routing: OFF
     • Address Translation
       • Source Translation: None
       • Destination Translation: SAT
       • Address Action: Single IP
       • Port Action: None
       • New IP Address: <Your_WAN_HA4_Object> - This is the critical part. Instead of a regular IP address object, use an HA4-IP object that is assigned to our wan1 network interface (can be seen in Network → Interfaces and VPN → Ethernet → YourExternalInterfaceName → Advanced tab → High availability(Private IP address)). The HA4-IP object includes both private IP addresses of your cluster nodes as well as the public IP address.:
     • Logging & Comments
       • Logging: ON (or Default, if preferred)
       • Comments: Add any relevant comments to describe the purpose of the rule.
3. Adjust Reconf Failover Time:
   • Go to System → Device → High Availability → Advanced.
   • Set "Reconf Failover Time" to 25 seconds.
   • Explanation: This setting delays the fail-over process during a configuration deployment. This is important because we are managing only the active node. If a fail-over occurs immediately after activation, the commit command might not be executed on the newly active node, leading to a configuration revert. Increasing the fail-over time ensures that the node where the configuration was activated remains active long enough for the commit command to be processed after the reconnect.
4. Deployment and Verification:
   • Deploy the configuration using the "Activate and Commit" method.
     • Activate: Activates the changes.
     • Wait for Reconnect: The management interface will briefly disconnect as the configuration is applied.
     • Commit: Permanently saves the configuration after a successful reconnection. This ensures that the configuration is saved only if the management connection is re-established with the active node.
   • Verification:
     1. After deploying the configuration, attempt to access the WebUI of your firewall using the shared public IP address. You should be connected to the active node.
     2. To test failover, you can manually trigger a role change from the System -> High Availability section or simulate a failure on the active node.
     3. After a role change, you should still be able to access the WebUI using the same shared public IP, but you will now be connected to the new active node.

Advantages of this Simplified Method

• Dynamic Redirection: The HA4-IP object automatically handles directing traffic to the active node.

Important Notes

• This method assumes that you are managing the cluster using HTTPS. If you require SSH access, create a similar IP Policy rule using the SSH service.
• If you are using a DHCP-assigned public IP address, the concept is the same. You will need to make sure the interface is set to use an HA-IP and an HA4-IP object.
• Security: It is strongly recommended to restrict management access to specific source IP addresses or networks in the IP Policy rule for enhanced security.

Conclusion

This simplified approach offers a streamlined and efficient way to manage an HA cluster with a single public IP address. By leveraging the HA4-IP object within an IP Policy rule, you can achieve dynamic management access to the active node. Remember to adjust the Reconf Failover Time to ensure proper configuration deployment and commit.

Question: Will this work towards InControl?

Answer: The base scenario will not work towards InControl, but only for WebUI / SSH. Using the concept of accessing both nodes at the same time using different ports “may” work but it is a scenario/concept that has not been tested or verified by Clavister.

Related articles