NTP Server in pfSense - Network Time Synchronization

Accurate time synchronization is a fundamental requirement for reliable network infrastructure. Clock discrepancies affect log timestamp accuracy, SSL/TLS certificate validation, authentication protocols (Kerberos, RADIUS), CARP cluster coordination, and replicated file system integrity. pfSense includes a built-in NTP server based on the ntpd daemon that synchronizes its own clock with external reference sources and provides precise time to all devices on the local network.

Why Accurate Time Matters

Incorrect time synchronization leads to practical problems that are not always obvious during troubleshooting.

AreaImpact of Clock Drift
LoggingIncorrect timestamps make cross-device event correlation impossible
SSL/TLSCertificates rejected as expired or not yet valid
KerberosAuthentication fails when clock skew exceeds 5 minutes
CARPFailover cluster operates incorrectly
TOTPOne-time passwords do not match the server-generated values
BackupsIncremental backups include unnecessary files due to incorrect timestamps

Before serving NTP to clients, it is essential to ensure that pfSense itself maintains accurate time. By default, pfSense synchronizes with servers from the pool.ntp.org pool at system startup.

Clock Bootstrap

During startup, pfSense performs an initial clock synchronization. If the offset from reference servers exceeds 1000 seconds, ntpd refuses to make the adjustment and exits. In such cases, pfSense uses the ntpdate utility to force-set the time before starting ntpd.

This process is particularly important for systems without a hardware real-time clock (RTC), such as virtual machines, where system time may deviate significantly after a reboot.

NTP Server Configuration

The NTP server is configured under Services > NTP.

Upstream Time Servers

The NTP Servers section defines the external time sources that pfSense synchronizes with.

FieldDescription
Time ServerAddress or hostname of the NTP server
PreferMark the server as the preferred source
No SelectExclude from synchronization while continuing to collect statistics

Configuring three to five servers is recommended. Three servers allow ntpd to determine which source is providing incorrect time through a majority selection algorithm. Fewer than three servers prevent ntpd from detecting a faulty source.

Recommended Servers

ServerDescription
0.pfsense.pool.ntp.orgDefault pfSense pool
1.pfsense.pool.ntp.orgDefault pfSense pool
2.pfsense.pool.ntp.orgDefault pfSense pool
time.cloudflare.comCloudflare NTP (Stratum 3)
time.google.comGoogle NTP (Stratum 1)
time.nist.govUS National Institute of Standards and Technology

If an internal Stratum 1 NTP server is available (for example, one equipped with a GPS receiver), it should be listed as the preferred source with the Prefer flag enabled.

Interface Binding

By default, the NTP server accepts requests on all pfSense interfaces. To restrict access, select specific interfaces.

ScenarioRecommended Interfaces
Standard networkLAN
Network with VLANsLAN, VLAN10, VLAN20
pfSense onlyLocalhost (NTP does not serve clients)

Warning:

Interface selection affects both incoming request handling and outbound queries to upstream servers. Selecting only the LAN interface may prevent pfSense from reaching external NTP servers through WAN.

Orphan Mode

Orphan Mode ensures that clients continue to receive time even when all upstream servers are unreachable. When activated, pfSense advertises itself as a time source at the specified stratum level using its internal clock.

SettingDescriptionDefault
Orphan ModeEnable the modeDisabled
StratumStratum level advertised to clients12

A stratum value of 12 signals to clients that this source is unreliable and should only be used when no alternatives are available. Do not set this value below 5 to avoid prioritizing the local clock over internet servers.

Orphan Mode is useful in air-gapped networks without internet access and for preventing complete synchronization loss during brief connectivity outages.

Access Restrictions

The pfSense NTP server supports access control lists for managing which clients may use the service.

Default Restrictions

Default restrictions apply to all clients that do not match a specific rule.

RestrictionDescription
Kiss-o’-DeathSend KoD packets to clients exceeding the allowed query rate
ModificationsBlock configuration changes via ntpq and ntpdc
QueriesBlock status queries via ntpq and ntpdc
ServeLimit the types of packets served
PeerPrevent new peering associations
TrapDisable remote event logging

Custom Restrictions

Custom rules with individual settings can be created for specific subnets. This allows, for example, granting full access to internal clients while restricting access from a guest network.

GPS and PPS Reference Clocks

For environments requiring high-precision synchronization, pfSense supports hardware time sources - GPS receivers and PPS signals.

Serial GPS

pfSense can use a GPS receiver connected through a serial port as a reference clock.

SettingDescription
GPS TypeGPS receiver model from the list or Custom
Serial PortConnection port (cuau0 for hardware, cuaU0 for USB serial)
Baud RateSerial port speed (typically 4800 bps)
NMEA SentencesNMEA message types to interpret
Fudge Time 1PPS signal offset correction (seconds)
Fudge Time 2GPS data offset correction (seconds)
StratumStratum level advertised for GPS (default: 0)

A GPS receiver with PPS output provides microsecond-level synchronization accuracy, surpassing any network-based NTP server.

Warning:

USB GPS receivers may function, but they are not reliable time sources due to inconsistent USB bus latency. For accurate synchronization, use receivers connected through a hardware serial port.

PPS (Pulse Per Second)

A PPS signal is an electrical pulse at 1 Hz frequency generated by a GPS receiver or another device. This signal enables sub-microsecond synchronization accuracy.

PPS settings in pfSense:

SettingDescription
PPS Signal ProcessingEnable PPS processing
Falling EdgeUse the falling edge of the pulse
Kernel PPS Clock DisciplinePass the PPS signal directly to the OS kernel

Kernel PPS Clock Discipline provides maximum accuracy but requires hardware serial port support and correct driver configuration.

Distributing NTP to Clients via DHCP

To configure NTP automatically on client devices, the NTP server address should be distributed through DHCP.

DHCP Option Configuration

Under Services > DHCP Server for the corresponding interface, enter the pfSense address in the NTP Server field. Client devices receiving a DHCP lease will automatically configure time synchronization with pfSense.

SettingValue
NTP Server 1pfSense LAN interface IP address
NTP Server 2Backup NTP server (optional)

Most operating systems (Windows, macOS, Linux) automatically apply NTP servers received through DHCP. Devices with static configurations require the NTP server to be set manually.

Monitoring NTP

Status > NTP

The Status > NTP page displays the current synchronization state.

ColumnDescription
StatusCurrent status of each upstream server
ServerNTP server address
Ref IDReference source identifier of the server
StratumNumber of hops from the reference source
OffsetDeviation from the local clock (milliseconds)
JitterVariation in delay between polls

Symbols in the Status column:

SymbolMeaning
*Current primary synchronization source
+Candidate for primary source
-Server excluded by the selection algorithm
xServer identified as a falseticker

Logging

NTP supports multiple logging levels configured under Services > NTP.

OptionDescription
Peer MessagesLog peer association events
System MessagesNTP system events
Statistics LoggingSave statistics to /var/log/ntp
Reference Clock StatisticsHardware source statistics
Clock Discipline StatisticsClock correction statistics

NTP logs are available under Status > System Logs on the NTP tab. RRD performance graphs are accessible through Status > Monitoring.

Troubleshooting

Time Not Synchronizing

  1. Verify upstream NTP server reachability: Diagnostics > Ping with the NTP server addresses
  2. Confirm that firewall rules allow outbound UDP traffic on port 123 from the WAN interface
  3. Check the NTP status on Status > NTP - at least one server should display the * symbol
  4. Review the log: Status > System Logs > NTP
  5. If the clock offset is significant, restart the NTP service through Status > Services

Significant Time Drift

  • Verify that pfSense is not running on a virtual machine with incorrect clock emulation settings
  • Ensure the hypervisor does not conflict with ntpd (VMware Tools and Hyper-V Integration Services sometimes adjust time in parallel with ntpd)
  • Increase the number of upstream servers to 4-5 for improved accuracy
  • Check the Jitter value on Status > NTP - values above 100 ms indicate an unstable network connection

Clients Not Receiving Time from pfSense

  1. Confirm that the NTP server is bound to the interface where clients reside
  2. Check firewall rules on the LAN interface - UDP traffic on port 123 must be permitted
  3. Verify DHCP settings - the pfSense address should be specified in the NTP Server field
  4. On a client device, run a test query: ntpdate -q <pfSense-ip> (Linux/macOS) or w32tm /stripchart /computer:<pfSense-ip> (Windows)

NTP Blocked by Firewall

NTP uses UDP port 123 for both inbound and outbound communication. Verify the following rules are in place:

DirectionSourceDestinationPortProtocol
Outbound (WAN)pfSenseAny123UDP
Inbound (LAN)LAN subnetpfSense LAN IP123UDP

ntpd vs chrony Comparison

pfSense uses the classic ntpd daemon. Linux distributions increasingly adopt the alternative implementation chrony. Key differences:

Characteristicntpd (pfSense)chrony
Initial synchronizationSlow (minutes)Fast (seconds)
VM operationRequires tuningAdapts automatically
Isolated networkOrphan ModeLocal stratum
GPS/PPSBuilt-in supportBuilt-in support
NTS protocolNot supportedSupported

pfSense does not support replacing ntpd with chrony. If chrony is required, deploy it on a separate server and configure pfSense to synchronize with it.

Related Sections

Last updated on