1

I'm trying to turn NTP on for a handful of EC2 instances inside a VPC, starting with ntpdate, since my server is pretty far off and I don't want it to slew.
I'm running into the 'no server suitable for synchronization' error:

bash-4.1$ sudo ntpdate -u 0.amazon.pool.ntp.org
2 Oct 16:21:05 ntpdate[20767]: no server suitable for synchronization found

There are a handful of posts on SO for this error already, and it is usually tied back to a firewall rule.

At the moment:

  • the instance is open on ALL ports, in and out (not just UDP/123).
  • the network ACL is open on ALL ports, in and out
  • DNS is on and 0.amazon.pool.ntp.org is resolving to actual addresses.
  • The NAT appears to be functioning, is able to reach other outside addresses using wget, (also, 0.amazon.pool.ntp.org resolves)

Obviously I can't leave th server wide open forever, this is just trying to diagnose the problem. I'm at a loss for what else to open up.

Here is the diagnostic trace:

2 Oct 16:25:06 ntpdate[20815]: ntpdate 4.2.6p5@1.2349-o Mon Mar  9 14:24:09             UTC 2015 (1)
Looking for host 0.amazon.pool.ntp.org and service ntp
host found : services.quadranet.com
transmit(198.55.111.50)
transmit(50.116.55.65)
transmit(108.61.194.85)
transmit(173.44.32.10)
transmit(198.55.111.50)
transmit(50.116.55.65)
transmit(108.61.194.85)
transmit(173.44.32.10)
transmit(198.55.111.50)
transmit(50.116.55.65)
transmit(108.61.194.85)
transmit(173.44.32.10)
transmit(198.55.111.50)
transmit(50.116.55.65)
transmit(108.61.194.85)
transmit(173.44.32.10)
transmit(198.55.111.50)
transmit(50.116.55.65)
transmit(108.61.194.85)
transmit(173.44.32.10)
198.55.111.50: Server dropped: no data
50.116.55.65: Server dropped: no data
108.61.194.85: Server dropped: no data
173.44.32.10: Server dropped: no data
server 198.55.111.50, port 123
stratum 0, precision 0, leap 00, trust 000
refid [198.55.111.50], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Sun, Dec 31 1899 19:00:00.000
originate timestamp: 00000000.00000000  Sun, Dec 31 1899 19:00:00.000
transmit timestamp:  d9b966a5.c841bbbb  Fri, Oct  2 2015 16:25:09.782
filter delay:  0.00000  0.00000  0.00000  0.00000
     0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
     0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 50.116.55.65, port 123
stratum 0, precision 0, leap 00, trust 000
refid [50.116.55.65], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Sun, Dec 31 1899 19:00:00.000
originate timestamp: 00000000.00000000  Sun, Dec 31 1899 19:00:00.000
transmit timestamp:  d9b966a5.fb750a47  Fri, Oct  2 2015 16:25:09.982
filter delay:  0.00000  0.00000  0.00000  0.00000
     0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
     0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 108.61.194.85, port 123
stratum 0, precision 0, leap 00, trust 000
refid [108.61.194.85], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Sun, Dec 31 1899 19:00:00.000
originate timestamp: 00000000.00000000  Sun, Dec 31 1899 19:00:00.000
transmit timestamp:  d9b966a6.2ea83387  Fri, Oct  2 2015 16:25:10.182
filter delay:  0.00000  0.00000  0.00000  0.00000
     0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
     0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

server 173.44.32.10, port 123
stratum 0, precision 0, leap 00, trust 000
refid [173.44.32.10], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Sun, Dec 31 1899 19:00:00.000
originate timestamp: 00000000.00000000  Sun, Dec 31 1899 19:00:00.000
transmit timestamp:  d9b966a6.61db63f1  Fri, Oct  2 2015 16:25:10.382
filter delay:  0.00000  0.00000  0.00000  0.00000
     0.00000  0.00000  0.00000  0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
     0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

 2 Oct 16:25:11 ntpdate[20815]: no server suitable for synchronization found

Suggestions please?

LizH
  • 241
  • 1
  • 11
  • Clearly, you're not getting replies. Either that's because something is blocking the queries or something is blocking the replies. You can tell which by querying a server you control and seeing if that server receives the queries. – David Schwartz Oct 02 '15 at 20:50
  • DNS *always* resolves in VPC. It's provided by the infrastructure, immune to security groups, and does not imply anything about the state of your instance's Internet access... which it does not sound like you have. – Michael - sqlbot Oct 03 '15 at 02:54
  • I don't think that is inherently true about DNS. There is a 'enable DNS' required for the infrastructure, but from a private subnet, I also had to open up port 53 at the gateway before DNS would work. The instance has internet access (the wide-open ports are not SOP). I've been running assorted services on it for months, and am able to query out using other services. The problem is specific to NTP. – LizH Oct 03 '15 at 14:51
  • Update: I need to research what the NAT is allowing through and isn't. Moved the same setup to a box on the other side of the NAT, and everything is awesome. Private subnet can synch to the public subnet, but not anything outside the VPC. This is still an port problem from inside the VPC - I can wget or curl to arbitrary internet addresses, for example. But apparently my NAT is filtering ports as well as the NACL and SGs. – LizH Oct 05 '15 at 10:02
  • We ran into a similar situation. The solution (in our case) was to allow _inbound_ UDP packets to port 123 in the security group for our NAT instance in our VPC. – Castaglia Jan 17 '16 at 19:42

0 Answers0