Имеется
DFL-800 как шлюз с двумя соединениями
Firmware: 2.27.03.25

В DMZ находится опорный сервер NTP (Linux), который синхронизируется с серверами в интернете.
С сервером NTP синхронизируется контроллер домена.
Проблема
DFL-800 не синхронизируется ни с опорным сервером NTP, ни с контроллером домена, ни с D-Link (pre-configured timesync server)
(точнее, синхронизация происходит только при перезагрузке устройства)

Настройки синхронизации
Automatic time synchronization
Custom
Primary Time Server: опорный сервер NTP
Secondary Time Server:внутренний сервер NTP(контроллер домена)
Tertiary Time Server: None

Interval between each synchronization: 3600
Maximum time drift that a server is allowed to adjust: 600
Interval according to which server responses will be grouped:10
Разница во времени между NTP и устройством в настоящий момент 5 минут (300)

Дополнительных разрешающих правил для DFL 800 нет

хз. могу чуток поэкспериментировать на своем DFL-210.

Посмотрите в руководстве по командной строке. Возможно, там есть более широкие средства тестирования NTP.

{прошло немного времени}
У меня с ручными настройками настройками нормально срабатывало от внешнего сервера dns:ru.pool.ntp.org или от внутреннего windows 2003 сервера.

интервал обновления был 120 секунд. сбивал время на DFL на 2-3 минуты (без применения и активации настроек). Он через 2 минуты его восстанавливал.

Все через web интерфейс.

DFL-210, f/w 2.27.03.25-14787

На основе своих опытов. я бы резюмировал, что ваши симптомы весьма странны, учитывая. что сам сервис у вас срабатывает при активации новой конфигурации (или исключительно при перезагрузке ?)

С аналогичными вам настройками, только на одном внутреннем сервере, у меня тоже нормально сработало.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

2YuriAM
Спасибо за подсказку глянуть в CLI. Про очевидные вещи на бегу всегда забываешь...

Итог
Получилась затянувшаяся первоапрельская шутка.

Генезис
Устройство синхронизирует часы на GMT, локальное время вычисляет из указанного сдвига.
При переходе на летнее время часы, видимо, установили руками (GMT+3 в настройке +1 час от души ) и, наверное, получилось не совсем точно .
В настройках переход на летнее время не включался.
Далее Maximum time drift that a server is allowed to adjust: 600

Эпикриз:
В результате устройство честно получало время от сервера NTP, убеждалось что не имеет права корректировать такое большое расхождение и
продолжало жить по своим внутренним часам. При принудительной синхронизации из CLI (time -sync -force) оно, во-первых,
засинхронизировалось, не обращая внимание на Maximum time drift that a server is allowed to adjust. Во-вторых, оно показало дрифт,
из значения которого стало понятно, в чем проблема.

Лечением проблемы стала установка Time zone GMT+4 (Абу Дабу, Баку, Тбилиси)

Если время назад больше переводиться не будет, то это значить, что GMT+03 - Москва, прощай...