Description | This article describes when the HA Cluster has HA-Direct enabled and FortiGate acts as an NTP server for the Internal host, and how allows NTP traffic to communicate with the FortiGuard NTP server properly. |
Scope | FortiGate. |
Solution |
When FortiGate is set in Active-Passive Cluster and has configured with management Interface Reservation, NTP traffic will initiate from the Management interface, this behavior has been described in this document: Out-of-band management with reserved management interfaces
This will override the source-ip setting hence even if explicitly set source IP is under the NTP setting, FortiGate will not use the source IP to communicate with the NTP server. The following example describes when HA direct NOT enabled and enabled traffic flow.
Case 1: HA Direct is not enabled.
Settings for an HA cluster.
The NTP status on the FortiGate site, the output of the command 'diagnose system ntp status' shows HA synchronization: yes.
Port1 is my WAN port.
Windows Server as an NTP client before does not have NTP synced. See below, time is not synced to align the FortiGate.
Here is the FortiGate setting for NTP, port 4 will act as the NTP server from a Windows perspective.
Date and time on FortiGate.
Once the full NTP command is installed on Windows, it gets synced:
Windows is sending the traffic toward FortiGate port4 and can get time synced (10.68.1.45 is the Windows server).
Case 2: Enable HA Direct under the HA setting, this is only can be done in the command line.
That will give the warning that the source IP may not work. Once HA-direct is enabled, FortiGate NTP out of sync based on the output below: synchronized: no.
The way to make it work will be to use the HA management Interface Gateway.
The gateway here will be the next hop to let MGMT traffic communicate with the FortiGuard NTP server. 10.68.1.60 is the MGMT port in this FortiGate. There is 10.68.1.92 from another FortiGate interface port3 (subject to change depending on network setup however ensure the Gateway IP address has been set here will stay at the same subnet of 10.68.1.60 which is PORT4 MGMT interface). The reason for gateway is required because once the Management Interface reservation has been configured under the HA cluster, the routing table will be moved from global, see below the generic routing table on FortiGate Cluster.
Port4 which is the Management Interface IP address is not showing under the generic routing table. This behavior is described here: Reference link for hidden vdom
To verify the management routing table we need to enter the hidden VDOM below:
execute enter vsys_hamgmt get router info routing-table all <----- This will show the routing table for the management interface hence it is necessary to have the gateway stay at the same subnet with the management interface here to route out the NTP traffic.
Gateway 10.68.1.92 needs to be able to reach the Internet or FortiGuard NTP server.
Note: This hidden VDOM 'vsys_hamgmt' has separated the MGMT interface from the interfaces in other VDOMs and no Inter-VDOM link is configurable from this hidden VDOM to any other VDOMs. This means the traffic from the MGMT interface cannot go back to any other VDOMs but only to the other device it connects. So, the gateway of the HA management interface could only be other devices it is directly connected in layer 3.
NTP traffic will be HA Fortigate cluster -----> MGMT interface (port 4) ----> port 3 another Fortigate -----> Internet/Fortiguard NTP server
Once the above change has been processed, the NTP can sync:
Setting the source IP for NTP might not work, only the packet coming is visible into this interface but not routing anymore.
|
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.