Short answer: a local NTP server gives every authorized device on a company network one controlled and consistent source of time. NetSmart synchronizes with trusted upstream NTP servers, serves that time to internal clients, fails over between configured sources, and lets administrators monitor synchronization from one web panel.
Accurate time is a basic requirement for a reliable company network. Servers, workstations, firewalls, cameras, switches, applications, and security systems all create timestamped data. When those devices disagree about the time, logs become difficult to compare, scheduled jobs can run at the wrong moment, certificates may appear invalid, and authentication systems can fail.
NetSmart includes a local Network Time Protocol (NTP) service that provides one internal time source. It synchronizes with selected external NTP servers and then supplies synchronized time to clients on the local network.
What is a local NTP server?
NTP is the standard protocol computers and network devices use to synchronize their clocks. It normally uses UDP port 123. A local NTP server is an internal host that obtains time from trusted upstream sources and provides that time to authorized devices inside the organization.
Trusted upstream NTP servers
|
v
NetSmart NTP service
|
Company local network
|
Servers, PCs, switches, cameras,
firewalls, applications, and IoTNetSmart checks its configured upstream servers and calculates the clock offset. Local clients query NetSmart instead of contacting public NTP services individually. For protocol details, see the NTP version 4 specification, RFC 5905.
Why does accurate network time matter?
Reliable logs and troubleshooting
During an outage or security investigation, administrators often compare events from several systems. A firewall may record a connection, a server may record a login, and an application may record a data change. If their clocks differ, the sequence of events becomes unclear.
With one local time source, log entries from different systems share a consistent timeline. This makes troubleshooting faster and audit evidence more dependable.
Authentication, certificates, and security
Many authentication mechanisms and signed requests use time to limit replay attacks. Directory environments, single sign-on systems, API tokens, and other security controls may reject a request when client and server clocks differ too much.
TLS certificates also have validity dates. An incorrect system clock can make a valid certificate appear expired or not yet valid. Consistent time prevents avoidable login and certificate errors.
Scheduled work and business applications
Backups, reports, database maintenance, monitoring checks, software updates, and automated workflows depend on schedules. Synchronized clocks help these jobs run in the expected order and make their results easier to verify.
Monitoring and physical security
Monitoring platforms need aligned timestamps to correlate alerts. The same applies to access-control systems, CCTV cameras, network equipment, and industrial or IoT devices. A local NTP service helps ensure that an event has the same timestamp everywhere it is recorded.
Why use one internal NTP service?
| Benefit | Operational value |
|---|---|
| Consistent time | Logs, transactions, alerts, and recordings follow one shared timeline. |
| Centralized control | Administrators select trusted upstream providers once instead of configuring every client separately. |
| Better visibility | NetSmart displays service status, active upstream, last synchronization, offset, errors, and logs. |
| Upstream failover | NetSmart moves to the next configured source if a higher-priority server is unavailable or returns an invalid response. |
| Simpler firewall policy | Only the NetSmart host needs outbound NTP access; internal clients query NetSmart over UDP port 123. |
| Restricted-network support | Devices without direct internet access can synchronize through the internal network. |
After a successful upstream synchronization, NetSmart can continue serving its calculated time during a temporary connectivity loss. Upstream access should be restored promptly because every software clock drifts over time.
What NTP features does NetSmart provide?
- Standard NTP service on UDP port 123, with a configurable listening port
- Automatic service startup
- Configurable synchronization interval and upstream request timeout
- Multiple upstream servers in administrator-defined priority order
- Automatic failover when an upstream server is unavailable
- Manual Synchronize Now action
- Live service status, active upstream, last synchronization time, and offset display
- Error reporting, activity logs, and UDP port-usage diagnostics
- Persistent settings managed from the same panel as other NetSmart services
Organizations should choose independent upstream sources that match their location, security policy, accuracy needs, and availability requirements.
How to deploy NetSmart as a local NTP server
- Run NetSmart on an always-on server or virtual machine with a stable local IP address.
- Allow inbound UDP port 123 from only the internal networks that need time synchronization.
- Configure at least two trusted upstream NTP servers in priority order.
- Allow outbound UDP port 123 from the NetSmart host to the approved upstream servers.
- Enable automatic startup and choose a synchronization interval appropriate for the environment.
- Assign an internal DNS name, such as
ntp.company.local. - Configure servers, workstations, hypervisors, switches, firewalls, cameras, and other devices to use the DNS name or stable IP address.
- Monitor the active upstream, last synchronization time, clock offset, and NTP logs from the NetSmart panel.
For the broader platform setup, follow the NetSmart Docker deployment guide.
NTP firewall, container, and security requirements
NTP uses UDP, so both the host firewall and network firewall must permit UDP port 123. When NetSmart runs in a container, the port must also be published correctly by the container network configuration. On Linux, binding to the standard port may require elevated privileges or an appropriate container capability.
Only authorized internal clients should normally be allowed to query the company NTP service. Do not expose it broadly to the public internet unless the service has been intentionally designed, secured, rate-limited, and monitored for public use.
Monitor the NetSmart health indicators. If all upstream servers fail, the panel records the error. Clients should not rely indefinitely on a server that has lost synchronization because its clock will drift.
When is one local NTP server not enough?
A single internal server is practical for many small environments, but it is also a single point of failure. Organizations that require greater availability should deploy more than one internal time server and distribute clients between them. NetSmart can be one part of that design.
Environments that require legally traceable time, extremely high precision, or operation without upstream network access should also consider dedicated GPS, GNSS, radio, or hardware reference clocks.
Frequently asked questions
Which port does NTP use?
NTP normally uses UDP port 123. Permit it only between approved internal clients and the NetSmart host, and between the NetSmart host and approved upstream NTP servers.
How many upstream NTP servers should a company configure?
Configure at least two trusted upstream servers so NetSmart can fail over when the preferred source is unavailable. Larger or higher-availability environments may require additional independent sources and more than one internal server.
Should every company device contact public NTP servers?
Usually no. Direct access from every device creates inconsistent configuration and a broader outbound firewall policy. A local NTP service centralizes provider selection, monitoring, and client access.
Can NetSmart serve time if the internet connection fails?
After a successful synchronization, NetSmart can continue serving its calculated time during a temporary upstream outage. Restore connectivity promptly and monitor synchronization state because the local software clock will drift over time.
Should a local NTP server be exposed to the public internet?
Normally no. Restrict queries to authorized internal networks unless the service has been deliberately engineered, secured, rate-limited, and monitored for public operation.
One shared timeline for the company network
A local NTP service supports authentication, logs, monitoring, scheduled tasks, security appliances, cameras, and business applications. NetSmart provides a central web interface for trusted upstream configuration, automatic failover, service health, synchronization status, and diagnostics.
Making NetSmart a standard internal time source creates a network that is easier to operate, troubleshoot, secure, and audit. Explore NetSmart features and deployment information.