Устранение неполадок нежелательного трафика NTP

Контроллер домена под управлением Windows Server 2012 отправляет трафик NTP и NETBIOS на адрес, который никогда не был настроен в качестве поставщика времени. Журналы сервера не показывают, что какой-либо трафик NTP не работает. Единственное место, где я вижу доказательства этого трафика, - это системные журналы pfSense:

(Blocked) Jun 9 08:48:50   DOMAIN   10.0.1.100:123   192.128.127.254:123   UDP
(Blocked) Jun 9 08:48:53   DOMAIN   10.0.1.100:137   192.128.127.254:137   UDP

Насколько я могу судить, в противном случае служба NTP работает нормально:

DC2.domain.com[10.0.1.101:123]:
    ICMP: 0ms delay
    NTP: -0.0131705s offset from DC1.domain.com
        RefID: DC1.domain.com [10.0.1.100]
        Stratum: 3
DC1.domain.com *** PDC ***[10.0.1.100:123]:
    ICMP: 0ms delay
    NTP: +0.0000000s offset from DC1.domain.com
        RefID: clock1.albyny.inoc.net [64.246.132.14]
        Stratum: 2

The time provider NtpClient is currently receiving valid time data from 1.pool.ntp.org,0×1 (ntp.m|0x0|0.0.0.0:123->204.2.134.163:123).
The time provider NtpClient is currently receiving valid time data from 0.pool.ntp.org,0×1 (ntp.m|0x0|0.0.0.0:123->64.246.132.14:123).
The time service is now synchronizing the system time with the time source 0.pool.ntp.org,0×1 (ntp.m|0x0|0.0.0.0:123->64.246.132.14:123).

Я был внутри и вне конфигурации NTP и не могу найти причину этого трафика. Обратный DNS указывает адрес назначения на nothing.attdns.com. звон nothing.attdns.com от рассматриваемого контроллера домена приводит к ответу от loopback (127.0.0.2), что вызывает у меня головную боль.

Любые идеи?

РЕДАКТИРОВАТЬ1: вероятно, следует отметить, что после сброса DNS nslookup 192.128.127.254 не возвращает ничего.attdns.com. 192.128.127.254 отсутствует в записях DNS domain.com. Домен attdns.com отсутствует в кэшированных поисковых запросах. 127.in-addr.arpa свободен от всякого фанкета.

РЕДАКТИРОВАТЬ2: ответ ping обратной петли от ничего.attdns.com, возможно, не связан. Машины в других сетях также демонстрируют такое поведение.

EDIT3: Как упоминалось в комментариях, я отследил проблемный сетевой адаптер обратно на мою виртуальную машину pfSense, размещенную в esxi 5.5 (я знаю, что мне стыдно за виртуализацию брандмауэра). pfSense был настроен на использование DC1.domain.com в качестве основного поставщика времени, но после изменения его обратно на pool.ntp.org проблема не исчезла. Журналы pfSense не указывают на неправильную конфигурацию NTP. Везде, где я могу подумать, эта виртуальная машина обозначена как 10.0.1.253, поэтому я до сих пор не понимаю, почему она отправляет запросы NTP как 192.128 ... Поскольку этот межсетевой экран был временным решением проблемы, которой больше не существует, я собираюсь списать ее .

EDIT4: запросы поступали с другой машины, использующей тот же виртуальный адаптер, что и брандмауэр. У машины есть два локальных адаптера: один для LAN, а другой для подключенного оборудования, которое использует соединение Ethernet. Это оборудование находится в загадочной подсети, и машина передает запросы NTP через оба адаптера.