Sophos Firewall as NTP relay: forward NTP via NAT

In many networks, clients, servers, switches, access points or special devices should simply use the Gateway-IP as a time server. In this scenario, however, there is no complete internal NTP server running on Sophos Firewall, which itself provides the time for clients.

The practical workaround is an NTP relay via NAT. Devices send NTP to the firewall IP, and Sophos Firewall forwards these requests to a real external or internal time server. The firewall does not become the actual time source; it translates and permits the matching traffic.

This is particularly useful if devices are permanently configured to the Gateway-IP, if a previous UTM environment has been replaced or if you want to centrally control NTP targets. For new DHCP designs, it is often cleaner to distribute the correct time server directly via the DHCP option. The basics can be found in Sophos Firewall Configure DHCP Options.

⚠️ Important: The Sophos Firewall should not provide an open NTP service to the Internet. Source zones, source networks, target servers and firewall rules must be deliberately restricted. WAN as Source Zone is usually incorrect for this pattern.

Which variant is suitable?

NTP via NAT is a pragmatic pattern, but not always the best architecture.

Two variants are important for this article:

• Variant A: Internal devices use the firewall IP as a NTP server, the firewall forwards to an external NTP server.
• Variant B: Internal devices use the firewall IP as a NTP server, the firewall forwards to an internal NTP server. In addition, the internal NTP server must be allowed to synchronize externally.

The second variant therefore needs two NAT rules and two firewall rules. This is the point that is missing from many brief notes on this topic.

Requirements

Before configuration, these points should be clear:

• Which internal networks are allowed to use NTP?
• Which IP address do clients use as the NTP destination, for example the Gateway-IP?
• Which real NTP server to use?
• Should an internal time server or an external service such as time.google.com or pool.ntp.org be used?
• Can the firewall reliably resolve DNS for FQDN targets?
• Is the firewall’s own system time synchronized correctly? Correct time is important for time-critical functions such as MFA, WAF authentication, certificates, logs, VPN and SIEM correlation. If the firewall itself has incorrect time, the system time should be checked first before redirecting Client-NTP.

The steps in this article are based on Sophos Firewall 22.0. Menu paths and field names can differ slightly in older or newer SFOS versions. The configuration belongs in the Sophos Firewall WebAdmin interface or in a carefully checked API/CLI automation. In Sophos Central, this NAT and firewall rule set is normally not managed as a dedicated NTP relay configuration.

The examples are intentionally described as an IPv4 setup because Sophos also shows the host creation in the official guide with IP version: IPv4. In IPv6 or dual-stack environments, this pattern should not simply be copied. First clarify whether clients really need NTP over IPv6, which firewall and NAT functions apply in the deployed SFOS release, and whether DHCPv6, Router Advertisements, or a direct internal time server is the cleaner design.

Quick Reference

For experienced admins, the short logic is simple: clients send UDP 123 to the firewall or gateway IP. A DNAT rule rewrites the destination to the real NTP server, a firewall rule permits exactly this traffic, and Log Viewer then confirms the Firewall Rule ID and NAT Rule ID.

External NTP server: A DNAT rule forwards NTP from the firewall IP to the FQDN or host object of the external NTP server. A firewall rule permits NTP from the affected internal sources towards WAN. The critical field is Original destination: it should point to the firewall or gateway IP.

Internal NTP server: Two flows are required. First, the internal NTP server must be allowed to synchronise externally via SNAT/MASQ. Second, a DNAT rule forwards client requests from the firewall IP to the internal NTP server. Both rule pairs should be checked separately in Log Viewer.

For the first implementation, the rule position should deliberately be high, typically Top or above broad LAN-to-WAN and general NAT rules. Afterwards, the position can be moved into the existing rule concept as long as Log Viewer and Packet Capture still show that the expected rule matches first.

Variant A: Use external NTP server

This variant is suitable if clients are to use the firewall IP as a NTP server and there is no own internal time server. The firewall translates the NTP request to an external time server, for example 1.sophos.pool.ntp.org, time.google.com or a deliberately chosen provider time server.

Create FQDN host for external NTP server

The menu path is:

Hosts and services > FQDN host

Procedure:

1. Select Add.
2. Assign Name, for example NTP_1_sophos_pool.
3. Enter the external NTP server under FQDN, for example 1.sophos.pool.ntp.org.
4. Save.

If an internal or external time server with a fixed IP is used instead of FQDN, a normal host object may make more sense. It is important that the target can be clearly recognized later in the NAT and firewall rule.

Create NAT rule for the external NTP server

The NAT rule ensures that NTP requests to the firewall IP are rewritten to the external time server. The menu path is:

Rules and policies > NAT rules

Procedure:

1. Select Add NAT rule > New NAT rule.
2. Set Rule name, for example DNAT_Client_NTP_to_External.
3. Set Rule position to Top or place above broad NAT rules.
4. Set Original source to the affected internal network, for example LAN_NET or IOT_NET.
5. Set Original destination to the firewall or Gateway-IP that clients use as the NTP server.
6. For Original service, remove Any and select NTP.
7. For Translated source (SNAT) select MASQ.
8. For Translated destination (DNAT), select the FQDN host or external NTP server host.
9. For Inbound interface, select the internal interface or the affected internal interfaces.
10. Save.

    

⚠️ Do not leave Original destination open: If Original destination is not limited to the firewall or gateway IP, the rule can have a much wider effect depending on the remaining NAT design. In some cases, not only traffic to the firewall IP is forwarded, but NTP traffic from the network is transparently redirected. For a controlled relay, the rule should only match when clients really use the firewall or gateway IP as their NTP destination. In the detailed view you should pay particular attention to four points: The original destination must really be the firewall or Gateway-IP, the service must remain limited to NTP or UDP 123, the translated destination must point to the planned time server, and SNAT should match the return route.

If NAT basics or DNAT fields are unclear, Understand NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT will help. It also explains why NAT does not replace a firewall release.

Allow firewall rule for external NTP

According to the NAT rule, a suitable firewall rule is required. This allows NTP traffic from the internal networks to the target server. The menu path is:

Rules and policies > Firewall rules

Procedure:

1. Select Add firewall rule > New firewall rule.
2. Set Rule name, for example LAN_to_External_NTP.
3. Set Rule position to Top or place it above general LAN-to-WAN rules if these would otherwise match first.
4. Activate Log firewall traffic.
5. Set Source zones to the internal zones, for example LAN, DMZ or an IoT zone. WAN and Any are incorrect for this pattern.
6. Set Source networks and devices to the affected networks or devices. Not a blanket Any if only certain networks should use NTP.
7. Set Destination zones to WAN.
8. Set Services to NTP.
9. Set Action to Accept.
10. Save.

In official or simplified examples, Source networks and devices is sometimes shown as Any. That is convenient in a lab, but rarely the best choice in production. A concrete network object such as LAN_NET, IOT_NET, or a small host group is cleaner, so it remains clear which devices may use this NTP forwarding.

The rule is mainly limited via Source Zone, Source Network, service, rule position and NAT target. If Destination networks is also to be used, you should then check the effect in Log Viewer, because DNAT rules can change the visible target address in the analysis.

Logging on this rule is helpful for the introduction. After the test, you should be able to see in the Log Viewer which client network the request came from, which Firewall Rule ID was used and whether the expected NAT Rule ID is also visible. If no Rule ID or the wrong rule appears, the order or match of the rule is more important than the NTP configuration itself.

For rule structure, sequence, Services and logging, Understanding and correctly configuring Sophos Firewall rules also fits.

Variant B: Use internal NTP server

This variant is suitable if an internal domain controller, Linux time server or other internal system is to be the time source for clients, but the clients continue to use the firewall IP as a NTP server.

Two pairs of rules are needed here:

Create host for internal NTP server

The menu path is:

Hosts and services

Procedure:

1. Select Add.
2. Set Name, for example NTP_Server_Internal.
3. Set IP version to IPv4 if IPv4 is used.
4. Set Type to IP.
5. Enter IP address of the internal NTP server.
6. Save.

Rule pair 1: Internal NTP server synchronizes externally

First, the internal NTP server must be able to reach an external time server itself if it is not already synchronized elsewhere.

NAT rule:

1. Open Rules and policies > NAT rules.
2. Select Add NAT rule > New NAT rule.
3. Set Rule name, for example SNAT_Internal_NTP_to_WAN.
4. Set Rule position to Top or place it appropriately above broad NAT rules.
5. Set Original source to host NTP_Server_Internal.
6. For Original service, remove Any and select NTP.
7. For Translated source (SNAT) select MASQ.
8. Save.

Firewall rule:

1. Open Rules and policies > Firewall rules.
2. Select Add firewall rule > New firewall rule.
3. Set Rule name, for example Internal_NTP_to_WAN.
4. Activate Log firewall traffic.
5. Set Source zones to the zone of the internal NTP server, for example LAN.
6. Set Source networks and devices to NTP_Server_Internal.
7. Set Destination zones to WAN.
8. Set Services to NTP.
9. Save.

Rule pair 2: Guide clients to the internal NTP server via firewall-IP

The actual forwarding is then built: clients send NTP to the firewall-IP, the firewall forwards to the internal NTP server.

NAT rule:

1. Open Rules and policies > NAT rules.
2. Select Add NAT rule > New NAT rule.
3. Set Rule name, for example DNAT_Client_NTP_to_Internal.
4. Set Rule position to Top or place it above general NAT rules.
5. Set Original source to the affected internal client networks.
6. Set Original destination to the firewall or Gateway-IP that clients use as the NTP destination.
7. For Original service, remove Any and select NTP.
8. For Translated source (SNAT), select MASQ.
9. For Translated destination (DNAT) select NTP_Server_Internal.
10. Save.

Here too, Original destination is critical: the rule should only translate NTP requests addressed to the firewall or gateway IP. If this field remains too broad, the firewall can also capture NTP requests that clients actually wanted to send directly to another time server.

Firewall rule:

1. Open Rules and policies > Firewall rules.
2. Select Add firewall rule > New firewall rule.
3. Set Rule name, for example LAN_to_Internal_NTP.
4. Activate Log firewall traffic.
5. Set Source zones to the internal client zones. Avoid WAN and Any.
6. Set Source networks and devices to the affected client networks.
7. Set Destination zones to the zone of the internal NTP server, for example LAN or DMZ.
8. Set Services to NTP.
9. Save. If a Destination network is also set, you should then specifically test whether the firewall rule continues to match according to DNAT. For initial acceptance, source network, destination zone, service, NAT rule and Log Viewer are usually the clearer control points.

If the internal NTP server itself is a domain controller, you should scope particularly carefully. Not every client network has to reach every domain controller directly. NTP can be allowed without opening equally wide domain controller accesses.

Operations, security and testing

Classify IPS and security features

NTP is technically a small UDP service, but UDP 123 also becomes relevant in practice for abuse, misconfiguration or unwanted external targets. If a Network Protection license is available, a suitable IPS policy on the firewall rule may make sense.

More important than as many security features as possible with the NTP is a tight design:

• Source Zone internal only: prevents the firewall from acting like a public NTP relay.
• Source Networks specifically: limits NTP to clients, servers or devices that really need this forwarding.
• Set Destination Server: prevents any external time servers and makes logs evaluable.
• Service only NTP: avoids too broad a UDP rule.
• Activate logging: shows in Log Viewer whether Firewall Rule ID and NAT Rule ID work as expected.

IPS should therefore be seen as additional control, not as a replacement for a clean rule. If the NTP rule only allows a few internal networks to a defined time server, the most important security gain is already achieved through scope and traceability. When a large number of networks, unclear devices or IoT/OT areas are involved, a targeted IPS policy becomes more interesting.

⚠️ IPS requires a suitable network protection license. If IPS is enabled on a very widely used rule, logs and performance should be monitored. For simple NTP forwarding, clean scoping is more important than an unnecessarily broad security feature combination.

If a dedicated IPS policy is used for this purpose, it should not be copied across the board to all internal networks. It makes more sense to have a small rule with a clear source, a defined NTP target, active logging and subsequent control in the Log Viewer.

Other security features should be deliberately treated cautiously with NTP. For this simple UDP service, Web Filtering, TLS Inspection, Application Control or Malware Scan usually do not help with the actual NTP function. If such profiles are active on a collective rule, it should be checked whether NTP would be better placed in its own, small rule.

Distribute NTP cleanly with DHCP

If the clients receive their network configuration via DHCP, you should check whether a NAT forwarding is even necessary. For many environments, it is cleaner to distribute the desired NTP server directly via DHCP.

If there is a domain controller or central time server, DHCP option 42 can point directly to this server. NAT is particularly useful if devices already use the Gateway-IP or are difficult to reconfigure. For DHCP special options, Sophos Firewall Configure DHCP Options is a better start.

Check firewall system time separately

The NTP client redirect is not the same as the Sophos Firewall system time. Both should be checked separately:

• Firewall system time: relevant for Log Viewer, certificates, MFA, VPN, WAF authentication, reports, Syslog and support analysis.
• Client-NTP via NAT: Devices in the internal network receive time via the Gateway-IP or a redirected NTP address.

If the firewall itself has an incorrect time or time zone, log entries may be difficult to correlate, certificate checks may fail, or time-based authentication such as TOTP/MFA may cause problems. Then the firewall system time and the firewall NTP access should be corrected first. Only then does it make sense to validate client NTP via NAT.

For SIEM or Syslog environments, this point is particularly important: the firewall can correctly route NTP traffic and still send incorrect timestamps to a SIEM if its own time or time zone is incorrect.

For log forwarding, Send Sophos Firewall Syslog to SIEM is suitable. For MFA problems, MFA for Sophos Firewall WebAdmin, VPN Enable Portal and Remote Access should also be included.

Test NTP and isolate errors

After saving, you should not only check whether the rule exists. What is crucial is whether a client can really synchronize NTP and whether the expected NAT and firewall rule is met.

The test begins the same for both variants: A client from the affected network uses the firewall or Gateway-IP as a NTP server. A time synchronization is then triggered or a short wait is carried out until the client sends NTP.

In Log Viewer you filter by service NTP or UDP 123.

With variant A it should be visible:

• The client comes from the expected internal network.
• The NTP firewall rule for external NTP hits.
• The DNAT rule matches the external time source.
• The target is the planned external NTP server.

Two things should be checked for variant B:

• The internal NTP server is allowed to send NTP externally.
• The clients are routed via DNAT from the firewall-IP to the internal NTP server. If the Log Viewer does not clearly show which rule applies, Diagnostics > Packet capture will help. There you should check whether packets from the client to UDP 123 arrive on the firewall and whether packets then continue to the expected external or internal time server.

If no logs are visible, the request cannot be sent to the client at all, the firewall rule is not logging, or the traffic takes a different path. Test firewall rule with Log Viewer, Policy Test and Packet Capture is suitable for the systematic check.

For firewall-specific NTP problems, the NTP client log is also relevant. The log overview is in Sophos Firewall Troubleshooting: Services and Logs.

Short acceptance

Before productive completion, five points should be correct:

1. Clients really use the firewall or Gateway-IP as NTP server.
2. The NTP rules only allow the intended internal source networks.
3. The expected Firewall Rule ID and NAT Rule ID are visible in the Log Viewer.
4. The firewall system time is correct separately.
5. After DHCP, VLAN, NAT or rule changes, NTP will be tested again.

Typical errors

• WAN allowed as Source Zone: The firewall can unintentionally act like an open NTP relay. Limit source zones to internal zones.
• Any for source and destination: The rule is difficult to control. Define source networks and target servers specifically.
• NAT rule present, but no firewall rule: Traffic is translated but not allowed. Check Log Viewer for Rule ID and NAT ID.
• Firewall rule without logging: Error analysis becomes unnecessarily difficult. Activate Log firewall traffic at least during test.
• FQDN target does not resolve: The DNAT target is not reached. Check the DNS resolution of the firewall.
• Client uses other NTP server: The rule is never met. Check client configuration or DHCP option.
• Time server not responding: The client remains unsynchronized. Check destination server, routing and UDP 123.

FAQ