clock synchronization for Meraki MR with NTP server

DarioGustin
Conversationalist

clock synchronization for Meraki MR with NTP server

Is there an option in the Meraki Dashboard to sync the clock with NTP servers? not to convert the device (Access Point in an NTP server but only sync the AP with a NTP server

19 Replies 19
PhilipDAth
Kind of a big deal
Kind of a big deal

It already does this.

DarioGustin
Conversationalist

Thanks Philip. Where is the option to define the NTP server? How can I get to it? Do you know the path of this option (configure the external NTP server)?

PhilipDAth
Kind of a big deal
Kind of a big deal

You can't define it.  It is "baked" in.

Rudi
Getting noticed

Hi Dario - you can check on your "Firewall Info" tab (Help -> Firewall Info) to see that the Merakis would like UDP port 123 open for an NTP connection, mine doesn't show a destination (just "Any" destination). I believe there is no option to select a specific NTP server.

Jim1
New here

Meraki devices use pool.ntp.org as the NTP servers

MConradt
Conversationalist

I have this same question.  For PCI DSS compliance network devices need to get their NTP from an internal NTP server, not all over the known world of internet NTP servers.  It is kind of like advertising to any NTP server around the world, HEY! OVER HERE, I have a network to attack!  Provided a malicious actor decided to join the NTP pool, but that would never happen.

cmr
Kind of a big deal
Kind of a big deal

If you need an internal ntp server, create a zone for ntp.org on internal DNS and create a host record called pool that points to your own internal NTP server.

 

 

If my answer solves your problem please click Accept as Solution so others can benefit from it.
PhilipDAth
Kind of a big deal
Kind of a big deal

>For PCI DSS compliance network devices need to get their NTP from an internal NTP server

 

This sounds wrong.  I just took a quick look over the specification and can't find anything referencing this.  So you are saying you can't even use a Government run rubidium based NTP clock source - a clock source more secure and more  heavily protected and managed than any internal NTP server you could hope to run yourself?

 

I can see references about being "allowed" to use an internal NTP server - but nothing saying you "must" use an internal NTP server.

MConradt
Conversationalist

PCI DSS 10.4.1 has the following.
Are the following processes implemented for critical systems to have the correct and consistent time:
(a) Do only designated central time server(s) receive time signals from external sources, and are time signals from external sources based on International Atomic Time or UTC?

 

I do not mind having a known official external clock source(s) for a few designated servers.

What I do not like is using ntp.pool.org and having all my access points getting time from NTP servers all over the world.

It doesn't make sense to me from a security perspective.

PhilipDAth
Kind of a big deal
Kind of a big deal

That seems to be a two parter to me.

 

>(a) Do only designated central time server(s) receive time signals from external sources

 

You can tick this one.  Meraki will be external.

 

>and are time signals from external sources based on International Atomic Time or UTC?

 

This is an (a) or (b) answer.  It doesn't appear to have any wrong answer.

MinnesotaKid
Conversationalist

Little late to the conversation on this one, but @PhilipDAth - would you happen to know of a whitepaper from Meraki that details the NTP configuration or settings that are baked in on the MR side of things? I've been looking around but only found a few forum posts on it. 

cmr
Kind of a big deal
Kind of a big deal

@MinnesotaKid there seem to be quite a few in use, just checked two networks of mine in the UK and the below are all used as NTP servers for APs:

 

185.120.34.123 - time.netweaver.uk
176.58.109.199 - time.videxio.net
185.83.169.27
195.219.205.9
85.199.214.98
81.21.65.168 - ns3.turbodns.co.uk
185.53.93.157 - ntp2.wirehive.net
51.89.151.183 - 183.ip-51.89.151.eu

 

Seems a bit of a mixed bag to me...

If my answer solves your problem please click Accept as Solution so others can benefit from it.
CptnCrnch
Kind of a big deal
Kind of a big deal

I assume it will simply point to some (sub-) pool.ntp.org.

PhilipDAth
Kind of a big deal
Kind of a big deal

@MinnesotaKid  I don't know if any published list of NTP servers.  I would be tempted to do a packet capture of port 53 and examine the DNS entries being asked for.

cmr
Kind of a big deal
Kind of a big deal

@PhilipDAth that's what I did and was somewhat surprised to find one network with all ~25 APs using two Ip addresses and a second network with ~10 APs using six different ones...

If my answer solves your problem please click Accept as Solution so others can benefit from it.
PhilipDAth
Kind of a big deal
Kind of a big deal

I just did a packet capture of an MR access point in bridge mode just after power cycling it.

 

It made zero NTP queries.

 

Perhaps the NTP queries being seen are from an SSID in bridge mode, and it is the clients making the NTP queries.

cmr
Kind of a big deal
Kind of a big deal

@PhilipDAth the SSIDs on the APs I listed the NTP queries from are in bridge mode.  I guess I must be missing something, but why would the client NTP traffic appear to come from the APs management IP address when all other client traffic comes from the client's IP?  Does the MR proxy or relay the NTP traffic?  

If my answer solves your problem please click Accept as Solution so others can benefit from it.
PhilipDAth
Kind of a big deal
Kind of a big deal

You would only see client NTP queries coming from the AP IP address if one of the SSIDs (such as guest) was in NAT mode.

cmr
Kind of a big deal
Kind of a big deal

@PhilipDAth all the NTP calls I traced were from APs where every SSID is in bridge mode, so it looks to me then like the APs themselves make a lot of different NTP calls...

If my answer solves your problem please click Accept as Solution so others can benefit from it.
Get notified when there are additional replies to this discussion.