Sophos Firewall as NTP relay: forward NTP via NAT

When internal devices need to use the gateway IP as their NTP destination, Sophos Firewall can forward their requests to a time server via NAT. The setting under Administration > Time, by contrast, only synchronises the firewall’s clock; it does not provide an NTP server service for clients.

Sophos documents an NTP relay using NAT for this purpose. Devices send NTP to the firewall IP; Sophos Firewall translates the source and destination and forwards the packets to a real external or internal time server. The firewall does not become the time source. Separately, it acts as an NTP client to synchronise its own clock.

This is particularly useful if devices are permanently configured to the gateway IP, if a previous UTM environment has been replaced or when central control of NTP destinations is needed. 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 an NTP server, the firewall forwards to an external NTP server.
• Variant B: Internal devices use the firewall IP as an NTP server, the firewall forwards to an internal NTP server. In addition, the internal NTP server must be allowed to synchronise externally.

The second variant therefore has two separate data paths. If external synchronisation for the internal time server is already permitted and translated appropriately, check and reuse the existing rule pair; additional identical rules are unnecessary.

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 synchronised correctly?

A consistent IPv4 example makes the relationships clear:

• net_Internet-LAN: 10.10.11.0/24, client ingress Port2 in zone of the internal client network.
• host_internal-firewall-ip: host 10.10.11.1, the firewall IP used by these clients.
• host_Google-NTP: FQDN time.google.com for variant A and, if needed, as the internal server’s external time source.
• NTP_Server_Internal: host 192.168.20.10, reachable through Port3 in zone DMZ, for variant B.

These private addresses, object names and interfaces are examples and must be replaced with the actual values. Select only networks that need the relay and their actual ingress interfaces; add a separate, equally restricted rule for IOT_NET if needed. Create the network and host objects under Hosts and services > IP host. For multiple gateway IPs, the corresponding source networks, ingress interfaces and destination addresses must be consistent. Before making changes, record the existing NAT/firewall rules, their order and the client’s time source; the actual time server must be reachable and accept requests from the firewall address used by MASQ.

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 following steps apply to Sophos Firewall 22.0. The firewall’s NTP settings can’t be synchronised from Sophos Fusion (formerly Sophos Central); configure them in WebAdmin, through the CLI, or through the API. The NAT and firewall steps below use WebAdmin.

The examples intentionally use an IPv4 setup, with IP version: IPv4 selected when creating the host. 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 external server’s FQDN or host object. A firewall rule permits NTP from the affected internal sources to WAN. Sophos leaves Original destination as Any in its general relay example. For the gateway-IP relay described here, restrict it to the exact firewall IP used by clients. This avoids silently redirecting direct NTP requests intended for other servers.

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.

host_internal-firewall-ip contains the Sophos Firewall’s internal LAN IP address, here 10.10.11.1. Clients use this address as their NTP server. Replace the example with your own client network’s internal firewall LAN IP, and adapt net_Internet-LAN (10.10.11.0/24), the ingress interface and source zone accordingly. In this setup, the client ingress is Port2; the internal NTP server in variant B is reached through Port3 in the DMZ zone. Both rules use the predefined NTP service; no additional UDP-only service is required for this guide. Check the example configuration on a pilot device using your own addresses and NTP sources. Select the zone assigned to the client network in your environment; “internal LAN zone” is a description, not a required zone name.

Under Hosts and services > IP host > Add, create the following two IPv4 objects and save each with Save. Reuse suitable existing objects where available.

Variant A: Use external NTP server

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

Google Public NTP (time.google.com) uses leap smear. Do not mix it with non-smeared time sources.

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 host_Google-NTP.
3. Enter the external NTP server under FQDN, for example time.google.com.
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 recognised 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, in this example net_Internet-LAN (10.10.11.0/24).
5. Set Original destination to host_internal-firewall-ip, in this example 10.10.11.1.
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, remove Any and select the actual client ingress interface, in this example Port2. Sophos also permits Any, but selecting the interface prevents matches on unintended ingress paths.
10. Leave Translated service (PAT) as Original so UDP 123 remains unchanged. Outbound interface stays Any for this DNAT rule; the route to the translated destination determines the egress interface.
11. 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 detail view, four points need particular attention: 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 permission granted by a firewall rule.

Allow firewall rule for external NTP

After creating 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 NTP_LAN_to_Google.
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 the internal LAN zone, 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 Destination networks to an IPv4 host object for the firewall or gateway IP that clients use as their NTP destination, for example host_internal-firewall-ip. If it does not exist, create it under Hosts and services > IP host > Add, using Type: IP and that exact IP address. It must match Original destination in the client DNAT rule, not the external NTP host.
9. Set Services to NTP.
10. Set Action to Accept.
11. 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 net_Internet-LAN, IOT_NET, or a small host group is cleaner, so it remains clear which devices may use this NTP forwarding.

For inbound DNAT, Sophos first determines the translated destination. Destination zones uses its zone, here WAN; Destination networks, however, uses the original destination, here the firewall or gateway IP. The actual time server remains Translated destination (DNAT) only. Sophos’s general NTP example omits Destination networks; this distinction follows its explicit DNAT and loopback examples. After a change, trigger a new NTP session from the client: established sessions are not re-evaluated against changed NAT rules. Before accepting the setup, check Firewall Rule ID, NAT Rule ID, and the incoming and forwarded packet paths as described in the testing section; configuration alone does not prove successful synchronisation.

Logging on this rule is helpful during implementation. After the test, Log Viewer should show 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, order, 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 an NTP server.

Check two data paths and their rule pairs here; suitable existing rules can be reused:

Create host for internal NTP server

The menu path is:

Hosts and services > IP host

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 the IP address of the internal NTP server, in this example 192.168.20.10.
6. Save.

Rule pair 1: Internal NTP server synchronises externally

First, the internal NTP server must be able to reach an external time server itself if it is not already synchronised elsewhere. Its configured upstream time source must be the actual time server, rather than the gateway IP used as a relay. Requests can only be redirected back to the server itself if its traffic also matches a relay DNAT rule with that server as the translated destination. In the example above, the source network and inbound interface prevent this match against the client DNAT rule; the incorrectly selected gateway IP may then provide no usable time.

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. Set Original destination to the planned external time source, in this example host_Google-NTP.
7. For Original service, remove Any and select NTP.
8. For Translated source (SNAT) select MASQ; Translated destination (DNAT) and Translated service (PAT) stay Original.
9. Set Inbound interface to the internal server’s ingress interface, in this example Port3; restrict Outbound interface to the WAN interface actually used. If there are multiple WAN connections, include all intended egress interfaces.
10. 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 internal NTP server’s zone, in this example DMZ.
6. Set Source networks and devices to NTP_Server_Internal.
7. Set Destination zones to WAN.
8. Set Destination networks to the same external time source as in the SNAT rule, in this example host_Google-NTP. There is no DNAT here; the original and actual destinations are identical.
9. Set Services to NTP and Action to Accept.
10. Place the rule above general rules that would otherwise match first, and save.

Rule pair 2: Forward clients to the internal NTP server via the 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, in this example net_Internet-LAN.
6. Set Original destination to the firewall or gateway IP that clients use as their NTP destination, in this example host_internal-firewall-ip.
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. For Inbound interface, select the affected internal client interfaces, in this example Port2.
11. Leave Translated service (PAT) as Original; Outbound interface stays Any for this DNAT rule.
12. 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 the internal LAN zone or DMZ.
8. Set Destination networks to the IPv4 host object for the originally addressed firewall or gateway IP, for example host_internal-firewall-ip, matching Original destination in the client DNAT rule. Do not select NTP_Server_Internal; that host remains Translated destination (DNAT).
9. Set Services to NTP.
10. Set Action to Accept. Place the rule above general rules that would otherwise match first, and save.

Here too, Destination zones comes from the translated internal destination, while Destination networks contains the original firewall or gateway IP. Check a new client session, rule IDs, and packet paths separately for this rule pair. MASQ ensures that replies return through the firewall, but it hides the original client IP from the internal NTP server. If the time server needs client addresses for logging or access control, use direct access with an appropriate return route instead of this relay pattern.

If the internal NTP server itself is a domain controller, scope the rules particularly carefully. Not every client network has to reach every domain controller directly. NTP can be allowed without also permitting broad access to domain controllers.

Operations, security and testing

Assess 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 licence is available, a suitable IPS policy on the firewall rule may make sense.

For NTP, a tightly scoped design matters more than enabling as many security features as possible:

• 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: restricts traffic matched by this relay rule to the defined time server and makes logs easier to interpret.
• 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 many networks, poorly documented devices or IoT/OT environments are involved, a targeted IPS policy becomes more interesting.

If IPS is used on this NTP rule, the assigned IPS policy should explicitly include NTP-related signatures (IPS patterns). This targets the additional protection at attacks against NTP services; describing a policy as generally suitable does not replace selecting those signatures.

⚠️ IPS requires a suitable network protection licence. 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 settings with DHCP

If clients receive their network configuration via DHCP, check whether NAT forwarding is needed at all. 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, provided the client actually supports and uses this option. Domain members may follow their domain time hierarchy instead, so check the effective time source on the client. 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.

Configure the firewall as an NTP client separately

Forwarding client NTP is not the same as configuring Sophos Firewall system time. Under Administration > Time, SFOS 22.0 offers three choices:

The following view shows the firewall clock settings with a predefined NTP server and the Europe/Zurich time zone. It does not configure the client relay; successful synchronization is checked separately.

• Use predefined NTP server is the default. The firewall uses NTPv3 and 0.sophos.pool.ntp.org.
• Use custom NTP server accepts an IPv4 address, IPv6 address, or domain name. Up to ten servers are checked in the displayed order.
• Do not use NTP server sets the date and time manually and isn’t recommended for normal operation.

After choosing a server, select Sync now, then Apply. Current time only updates after Sync now once WebAdmin is refreshed. Set the time zone for the firewall’s location on the same page.

⚠️ VPN impact: According to Sophos, changing NTP time servers reconnects all IPsec connections. Make this change in a suitable maintenance window.

Check the two data paths 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, Enable MFA for Sophos Firewall WebAdmin, VPN Portal and Remote Access should also be included.

Test NTP and isolate errors

After saving, check more than whether the rule exists. The decisive points are whether a client can actually synchronise using NTP and whether the expected NAT and firewall rules match.

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

Open Log viewer from the upper-right corner of WebAdmin. In the Firewall module, use Add filter for a rule, IP address, or port; alternatively, free-text search finds 123, a client address, or a rule name. Session logs may not appear immediately: the firewall logs the session at its internal Destroy event. For UDP, it may be necessary to wait until the session ends; UDP has no TCP connection teardown.

With variant A it should be visible:

• The client comes from the expected internal network.
• The NTP firewall rule for external NTP matches.
• 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 Log viewer doesn’t make the matching rule clear, use Diagnostics > Packet capture. Under Configure, the BPF expression port 123 restricts the capture to NTP. After turning on Packet capture, the incoming packet should show the client IP, firewall IP, and UDP 123; the forwarded packet shows the translated destination. NAT ID and Rule ID must match the new rules. Incoming and Forwarded confirm the path; Consumed instead identifies a packet intended for the firewall itself, while Violation and Reason explain a drop.

Successful forwarding alone does not confirm time synchronisation. The client’s NTP status must also show a valid response and a synchronised state; for variant B, check the internal time server’s synchronisation status too. The packet capture should show a response from the actual time server and, on the return path to the client, the originally addressed gateway IP as the source again. If there is no response, first check reachability, the return route and the time server’s access controls for the MASQ address.

For a negative test, a client in an internal network that is not permitted sends a new NTP request to the gateway IP. The new client DNAT rule and its associated allow rule must not match. If the request is forwarded anyway, look for an earlier or broader NAT/firewall rule. A request from a permitted client directly to another NTP address must not be redirected by this gateway-IP DNAT rule either. The remaining firewall policy determines whether direct NTP is allowed or blocked; this relay alone does not enforce a central time source for all traffic.

If no logs are visible, the client may not be sending the request 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.

Acceptance check

Before completing the production setup, check these five points:

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: Troubleshooting 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 never matches. Check client configuration or DHCP option.
• Time server not responding: The client remains unsynchronised. Check destination server, routing and UDP 123.

Rollback

If the relay causes problems, first disable the new client DNAT rule and trigger a fresh NTP test. Then disable its firewall rule. For variant B, remove the internal server’s SNAT and WAN firewall rules only if it no longer needs them for its own synchronisation. Delete rules and dedicated host objects only after confirming that they have no hits or dependencies. Finally, give clients a directly reachable NTP server, for example through DHCP option 42; otherwise they lose their time source.

FAQ