Description
This article describes use cases for the node-specific gateway setting in FortiAuthenticator, caveats, and alternative solutions.
Scope
FortiAuthenticator.
Solution
Introduction.
FortiAuthenticator active-passive clusters are usually deployed within a single location, and a single subnet.
Under some circumstances, it may be desirable to separate the primary and secondary node geographically, and have the HA interfaces in different subnets.
To this end, the node-specific gateway setting was added to FortiAuthenticator in firmware version 6.0.
Function of the node-specific gateway setting.
The node-specific gateway setting works by adding a default route to the FortiAuthenticator's routing table.
The default route is via the HA interface, and using the node-specific gateway. It essentially insures each FortiAuthenticator node is reachable on the HA interface.
In addition to allowing an active-passive cluster to be geographically separated, the setting is also frequently used to simply management access to the secondary node in a cluster.
Configuring the node-specific gateway.
The setting can be configured in GUI under System -> Administration -> High Availability.
Alternatively, via the CLI:
To function as intended, the gateway must be in the same subnet as the HA interface itself.
Caveats.
The node-specific gateway setting works by adding a default route.
If there is a different, already configured default route, the static default route may be overridden by the node-specific gateway setting.
This override usually only happens on the secondary node but may persist after a failover.
This means that traffic may be routed differently and behave differently if the secondary is in control.
FortiAuthenticator does NOT replace the node-specific default route in the event of a failover!
The routing table might only be updated after a reboot.
Below are example routing tables, assuming the HA interface is port3, and node-specific gateway to be 192.168.155.254.
Primary (with or without node-specific gateway):
diagnose netlink route
default via 192.168.1.1 dev port1 <----- Default route via port1.
10.0.1.0/24 dev port2 proto kernel scope link src 10.0.1.1
192.168.1.0/24 dev port1 proto kernel scope link src 192.168.1.99
169.254.0.0/26 dev port3 proto kernel scope link src 169.254.0.1 <----- HA interface.
172.16.0.0/24 via 10.0.1.3 dev port2
192.168.12.0/24 dev port4 proto kernel scope link src 192.168.12.79
192.168.100.0/24 via 10.0.1.3 dev port2
192.168.155.0/24 dev port3 proto kernel scope link src 192.168.155.1 <----- HA interface.
Secondary before failover (with node-specific gateway):
diagnose netlink route
default via 192.168.155.254 dev port3
169.254.0.0/26 dev port3 proto kernel scope link src 169.254.0.2
192.168.155.0/24 dev port3 proto kernel scope link src 192.168.155.2
Secondary AFTER failover (in control of the cluster):
diagnose netlink route
default via 192.168.155.254 dev port3 <----- Default route via HA interface.
10.0.1.0/24 dev port2 proto kernel scope link src 10.0.1.1
192.168.1.0/24 dev port1 proto kernel scope link src 192.168.1.99
169.254.0.0/26 dev port3 proto kernel scope link src 169.254.0.2 <----- HA interface.
172.16.0.0/24 via 10.0.1.3 dev port2
192.168.12.0/24 dev port4 proto kernel scope link src 192.168.12.79
192.168.100.0/24 via 10.0.1.3 dev port2
192.168.155.0/24 dev port3 proto kernel scope link src 192.168.155.2 <----- HA interface.
Due to this, using the node-specific gateway setting can introduce unforeseen issues in the event of a failover.
The setting should ONLY be used if an active-passive cluster cannot be added to the same subnet, and if the setting is used, special attention must be paid to routing configuration.
Note: The route for 169.254.0.0/26 is expected in active-passive cluster setups; the HA daemon sets this up automatically.
Alternatives:
There are several alternatives which may be configured instead of the node-specific gateway, especially if the only goal is management access to the primary or secondary node on their HA interfaces.
- Host in the same subnet.
Deploying a VM or other jump host in the same subnet as the HA interfaces can provide the desired access.
As traffic towards the HA interfaces will originate with the VM, within the same subnet, no further routing needs to be configured on the FortiAuthenticator cluster, and the node-specific gateway setting is not required to enable the access.
FortiAuthenticator automatically has a route via the HA interface configuration.
- Source (inbound) NAT.
If there is a gateway placed between the HA subnet and other infrastructure, and this gateway is capable of NAT, then enabling NAT can also allow for access. If the gateway applies source NAT to any traffic towards the HA interfaces, then this traffic will appear to come from the same subnet as the HA interfaces.
As the traffic (seemingly) comes from the same subnet, no additional routing needs to be configured on FortiAuthenticator, and no node-specific gateway setting is necessary for access.
- Additional static routes.
FortiAuthenticator does allow creation of static routes via the HA interface. These routes need to be configured on the primary, but will be synced to the secondary node.
The secondary disables all non-HA interfaces, and any routes depending on those interfaces are disabled as a consequence.
Any routes that use the HA interface, however, will be active, as the outgoing interface is up.
Example routing table of secondary:
diagnose netlink route
169.254.0.0/26 dev port3 proto kernel scope link src 169.254.0.2
172.16.0.0/24 via 192.168.155.254 dev port3
192.168.100.0/24 via 192.168.155.254 dev port3
192.168.155.0/24 dev port3 proto kernel scope link src 192.168.155.2
In this example, traffic from subnets 172.16.0.0/24 and 192.168.100.0/24 will be able to reach the secondary's HA interface, and replies have a correct outgoing route available.
Related documents:
FortiAuthenticator Administration Guide: High Availability
Technical Tip: How to configure FortiAuthenticator HA A-P cluster
