# Issues with NTP on Pi 3 **URL:** \ **Category:** balenaOS\ **Created:** [June 17, 2020, 8:13am UTC](https://forums.balena.io/t/issues-with-ntp-on-pi-3/134603 "2020-06-17T08:13:31Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![joearkay](https://avatars.discourse-cdn.com/v4/letter/j/8edcca/32.png) [@joearkay](https://forums.balena.io/u/joearkay)\ **Post date:** [June 17, 2020, 8:13am UTC](https://forums.balena.io/t/issues-with-ntp-on-pi-3/134603/1 "2020-06-17T08:13:31Z")
Hi all, I have a Pi 3 running OS 2.50.4 and am having problems with getting a correct system time. When I run `date` on the command line I get the 9th of June (today is the 17th). I thought it may have failed to sync time with an NTP server so I rebooted, but with the same issues. I suspected that the NTP services may be getting blocked by the firewall sat on the network this unit is installed into, so I asked the on-site IT team to open up port 123 UDP as per [the docs](https://www.balena.io/docs/reference/OS/network/2.x/#network-requirements) however I’m still seeing the same issues. Running [chronyc sources](https://www.balena.io/docs/reference/OS/time/#chrony) both before the firewall rule and after shows the following (in other words, it still can’t reach the NTP servers): ``` 210 Number of sources = 4 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^? time.cloudflare.com 0 14 0 - +0ns[+0ns] +/- 0ns ^? 183.ip-51-89-151.eu 0 14 0 - +0ns[+0ns] +/- 0ns ^? ntp1.doorhan.ru 0 14 0 - +0ns[+0ns] +/- 0ns ^? ns4.turbodns.co.uk 0 14 0 - +0ns[+0ns] +/- 0ns ``` So my question is: do you think the firewall has been updated incorrectly, thus still not allowing the requests to the NTP server through, or do you think there may be something else at play here? Is there any way natively through balenaOS to check whether the ports have correct access? Thanks all. ---
**Author:** ![sradevski](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/sradevski/32/1609_2.png) [@sradevski](https://forums.balena.io/u/sradevski)\ **Post date:** [June 17, 2020, 8:23am UTC](https://forums.balena.io/t/issues-with-ntp-on-pi-3/134603/2 "2020-06-17T08:23:37Z")
Hi there, it indeed sounds like a firewall issue. You can try running `chronyc -a 'burst 4/4'` while SSHed in the hostOS and see if the time is updated correctly. You could also try running a device on a different network just so you can check if you can reproduce the issue. Let us know how it goes, and we can investigate further if needed. ---
**Author:** ![joearkay](https://avatars.discourse-cdn.com/v4/letter/j/8edcca/32.png) [@joearkay](https://forums.balena.io/u/joearkay)\ **Post date:** [June 17, 2020, 8:26am UTC](https://forums.balena.io/t/issues-with-ntp-on-pi-3/134603/3 "2020-06-17T08:26:04Z")
> [@sradevski](#): > > chronyc -a ‘burst 4/4’ Hi thanks for this. So I’ve just tried running this and I get a `200 OK` back - which I assume just means the command ran ok? However checking `date` and `chronyc sources` still shows issues: ``` root@deff851:~# chronyc -a 'burst 4/4' 200 OK root@deff851:~# chronyc sources 210 Number of sources = 4 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^? time.cloudflare.com 0 14 0 - +0ns[+0ns] +/- 0ns ^? 183.ip-51-89-151.eu 0 14 0 - +0ns[+0ns] +/- 0ns ^? ntp1.doorhan.ru 0 14 0 - +0ns[+0ns] +/- 0ns ^? server1.quickdrivingtest> 0 14 0 - +0ns[+0ns] +/- 0ns root@deff851:~# date Tue Jun 9 15:38:57 UTC 2020 root@deff851:~# ``` ---
**Author:** ![mtoman](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/mtoman/32/3599_2.png) [@mtoman](https://forums.balena.io/u/mtoman)\ **Post date:** [June 17, 2020, 11:44am UTC](https://forums.balena.io/t/issues-with-ntp-on-pi-3/134603/4 "2020-06-17T11:44:15Z")
Hi, it does not look like the `chronyc -a 'burst 4/4'`command has fixed the time and it indeed looks like you can not access the NTP servers. Could you please confirm with your IT team that the UDP port 123 is open for _outgoing_ connections? Also, when NTP is blocked on firewall, it is usually because local servers are provided and you are expected to use those, could you please also check with your IT team whether there are some local NTP servers in place that you should use?