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.

Jaxaeon
  • 155
  • 3
  • 11
  • I assume incoming NTP connections are not open from the Internet, right? There has been too much abuse on this these days – LatinSuD Jun 09 '14 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 09 '14 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 09 '14 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 09 '14 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. (http://network-tools.com/nslook/Default.asp?domain=nothing.attdns.com) – Christopher Karel Jun 09 '14 at 19:12
  • Christopher: I think that's it. Wireshark is indicating that the destination MAC is the same as my pfSense firewall, which I recently reconfigured to use internal NTP. I still have no idea where the 192.128 IP configuration is coming from. I reconfigured pfSense to use public NTP, but I'm still seeing the traffic on my DC. – Jaxaeon Jun 09 '14 at 19:19
  • `Wireshark is indicating that the destination MAC is the same as my pfSense firewall` - As it should be. Every remote ip address will have a destination MAC of your firewall if the firewall is the DG for your internal clients. MAC addresses are locally significant. Your clients can't resolve the MAC address (via ARP) for the remote ip address. They resolve the MAC address for their DG, which is where they send traffic destined for the remote ip address. When packets are routed the source and destination MAC addresses are rewritten but the source and destination ip addresses remain the same. – joeqwerty Jun 11 '14 at 23:30
  • joeqwerty: I think was getting source and destination MAC addresses mixed up. That makes sense. – Jaxaeon Jun 12 '14 at 00:19

2 Answers2

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.

ssl
  • 141
  • 3
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.

Jaxaeon
  • 155
  • 3
  • 11