# NTP Server in pfSense - Network Time Synchronization

> Configuring the NTP server in pfSense - time synchronization for network devices, upstream server selection, GPS and PPS reference clocks

Source: https://opennix.org/en/docs/pfsense/services/pfsense-ntp/


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.

| Area | Impact of Clock Drift |
|---|---|
| **Logging** | Incorrect timestamps make cross-device event correlation impossible |
| **SSL/TLS** | Certificates rejected as expired or not yet valid |
| **Kerberos** | Authentication fails when clock skew exceeds 5 minutes |
| **CARP** | Failover cluster operates incorrectly |
| **TOTP** | One-time passwords do not match the server-generated values |
| **Backups** | Incremental 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.

| Field | Description |
|---|---|
| **Time Server** | Address or hostname of the NTP server |
| **Prefer** | Mark the server as the preferred source |
| **No Select** | Exclude 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

| Server | Description |
|---|---|
| `0.pfsense.pool.ntp.org` | Default pfSense pool |
| `1.pfsense.pool.ntp.org` | Default pfSense pool |
| `2.pfsense.pool.ntp.org` | Default pfSense pool |
| `time.cloudflare.com` | Cloudflare NTP (Stratum 3) |
| `time.google.com` | Google NTP (Stratum 1) |
| `time.nist.gov` | US 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.

| Scenario | Recommended Interfaces |
|---|---|
| Standard network | LAN |
| Network with VLANs | LAN, VLAN10, VLAN20 |
| pfSense only | Localhost (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.

| Setting | Description | Default |
|---|---|---|
| **Orphan Mode** | Enable the mode | Disabled |
| **Stratum** | Stratum level advertised to clients | 12 |

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.

| Restriction | Description |
|---|---|
| **Kiss-o'-Death** | Send KoD packets to clients exceeding the allowed query rate |
| **Modifications** | Block configuration changes via ntpq and ntpdc |
| **Queries** | Block status queries via ntpq and ntpdc |
| **Serve** | Limit the types of packets served |
| **Peer** | Prevent new peering associations |
| **Trap** | Disable 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.

| Setting | Description |
|---|---|
| **GPS Type** | GPS receiver model from the list or Custom |
| **Serial Port** | Connection port (`cuau0` for hardware, `cuaU0` for USB serial) |
| **Baud Rate** | Serial port speed (typically 4800 bps) |
| **NMEA Sentences** | NMEA message types to interpret |
| **Fudge Time 1** | PPS signal offset correction (seconds) |
| **Fudge Time 2** | GPS data offset correction (seconds) |
| **Stratum** | Stratum 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:

| Setting | Description |
|---|---|
| **PPS Signal Processing** | Enable PPS processing |
| **Falling Edge** | Use the falling edge of the pulse |
| **Kernel PPS Clock Discipline** | Pass 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.

| Setting | Value |
|---|---|
| **NTP Server 1** | pfSense LAN interface IP address |
| **NTP Server 2** | Backup 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.

| Column | Description |
|---|---|
| **Status** | Current status of each upstream server |
| **Server** | NTP server address |
| **Ref ID** | Reference source identifier of the server |
| **Stratum** | Number of hops from the reference source |
| **Offset** | Deviation from the local clock (milliseconds) |
| **Jitter** | Variation in delay between polls |

Symbols in the **Status** column:

| Symbol | Meaning |
|---|---|
| `*` | Current primary synchronization source |
| `+` | Candidate for primary source |
| `-` | Server excluded by the selection algorithm |
| `x` | Server identified as a falseticker |

### Logging

NTP supports multiple logging levels configured under **Services > NTP**.

| Option | Description |
|---|---|
| **Peer Messages** | Log peer association events |
| **System Messages** | NTP system events |
| **Statistics Logging** | Save statistics to `/var/log/ntp` |
| **Reference Clock Statistics** | Hardware source statistics |
| **Clock Discipline Statistics** | Clock 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:

| Direction | Source | Destination | Port | Protocol |
|---|---|---|---|---|
| Outbound (WAN) | pfSense | Any | 123 | UDP |
| Inbound (LAN) | LAN subnet | pfSense LAN IP | 123 | UDP |

## ntpd vs chrony Comparison

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

| Characteristic | ntpd (pfSense) | chrony |
|---|---|---|
| Initial synchronization | Slow (minutes) | Fast (seconds) |
| VM operation | Requires tuning | Adapts automatically |
| Isolated network | Orphan Mode | Local stratum |
| GPS/PPS | Built-in support | Built-in support |
| NTS protocol | Not supported | Supported |

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

- [DHCP Server](/docs/pfsense/services/pfsense-dhcp/) - distributing the NTP server address to clients via DHCP options
- [DNS (Resolver and Forwarder)](/docs/pfsense/services/pfsense-dns/) - resolving NTP server names from the pool.ntp.org pool
- [Firewall Rules](/docs/pfsense/firewall/pfsense-firewall-rules/) - controlling access to the NTP service and permitting outbound NTP queries