0

A domain controller running Windows Server 2012 is sending NTP and NETBIOS traffic to an address that has never been configured as a time provider. The server logs give no indication that any NTP traffic is failing. The only place I see any evidence of this traffic is in pfSense system logs:

(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

As far as I can tell the NTP service is working normally otherwise:

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).

I've been inside and out of the NTP configuration and cannot find any reason for this traffic. Reverse DNS points the destination address to nothing.attdns.com. pinging nothing.attdns.com from the domain controller in question leads to a response from loopback (127.0.0.2) which makes my head hurt.

Any ideas?

EDIT1: It should probably be noted that after a dns flush, nslookup 192.128.127.254 returns nothing.attdns.com. 192.128.127.254 is not present in domain.com DNS records. The attdns.com domain is not present in cached lookups. 127.in-addr.arpa is clean of any funkyness.

EDIT2: The loopback ping response from nothing.attdns.com is possibly unrelated. Machines on other networks are also displaying this behavior.

EDIT3: As mentioned in the comments, I tracked the problem network adapter back to my pfSense VM hosted in esxi 5.5 (I know shame on me for virtualizing a firewall). pfSense was configured to use DC1.domain.com as its primary time provider, but upon changing it back to pool.ntp.org the problem persists. pfSense logs give no indication of NTP misconfiguration. Everywhere I can think to look this VM is identified as 10.0.1.253, so I still have no idea why it’s sending NTP requests as 192.128… Since this firewall was a temporary solution to a problem that no longer exists so I am going to decommission it.

EDIT4: The queries were coming from another machine sharing the same virtual adapter as the firewall. The machine has two local adapters: one for LAN, and the other for attached hardware that uses an Ethernet connection. That hardware sits in the the mystery subnet, and the machine is broadcasting NTP requests over both adapters.

Improve this question
8
  • I assume incoming NTP connections are not open from the Internet, right? There has been too much abuse on this these days
    – LatinSuD
    Jun 9, 2014 at 16:48
  • If I understand your question, computers outside of this network cannot access this domain controller. All inbound blocked, no internet facing devices.
    – Jaxaeon
    Jun 9, 2014 at 17:14
  • 1
    Is it possible you have a typo in your name resolution somewhere? That IP address is only one digit off from the 192.168.0.0 address space, which might have correlated to one of your own devices. Maybe check your internal DNS A records, and make sure nothing accidentally resolves to it?
    – Christopher Karel
    Jun 9, 2014 at 17:24
  • I thought of this as well. In fact, my IP dyslexia had me convinced that this was a rogue internal IP address for a while. As far as I can tell there are no IP's outside of the 10.0.1.0/24 subnet in my DNS A records.
    – Jaxaeon
    Jun 9, 2014 at 17:28
  • Yeah, the loopback address for nothing.attdns.com is in attdns.com's DNS records, that's not a problem with you. (network-tools.com/nslook/Default.asp?domain=nothing.attdns.com)
    – Christopher Karel
    Jun 9, 2014 at 19:12

2 Answers 2

Reset to default
0

Is the server's IP set statically or via dhcp? This is a wild idea, but if the server is using dhcp, is a bad ntp server option being passed to the server? I once had an issue with servers using the wrong ntp source, and it was because the dhcp server was configured to send the ntp option, and it was sending bad ip addresses for servers.

Oh, and also check the hosts file on the server for some weird DNS host setting.

Improve this answer
0

From Microsoft kb959119 :

When a multiple Network Time Protocol (NTP) client begins to look for a Time service host, it may send NTP packets over an interface with the wrong host address. The NTP client may send NTP packets from a host address of NIC #1 over NIC #2's subnet.

The Windows Time Service binds to all available networks when the Windows Server 2003 operating system searches for a time service host. Upon finding a host, it will stop broadcasting on every network but the one where it found a time service host.

In my situation, a Win XP VM was configured with two NICs. One for LAN and the other for third party hardware over Ethernet. The third party hardware was using the 192.128.x.x subnet. I was seeing the traffic in pfSense because my egress filtering was preventing DC1 from communicating with that public address space.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.