Tired of seeing outbound NTP blocks in your firewall logs because you restrict outgoing traffic? Or maybe you are receiving alerts because some device uses NTP pool resources (such as pool.ntp.org) and one of those IP addresses has ended up on a blacklist, blocklist, threat intelligence feed, etc? Either way, few things in the life of an IT or security professional are as frustrating as false positives. This write-up will help you change that with a little NAT magic, aka redirection. First and foremost, if you can modify the device’s NTP server please make the modification there instead! This post is for the times where that is not possible.

Changelog
28Dec2017 – Originally posted
18Feb2018 – Added to alias/inverted NAT rule
6Jan2019 – Clarified verbiage on rule order after NAT creation

Pooled NTP Servers on Blocklists

As shown in the commands below, running ntpdate to sync your time against a non-blocked hostname or IP address returns the time offset without issue. However, running the same command against a known blocked IP address just adds to your count whether it is firewall blocks, pfBlockerNG, Snort, or Suricata. What to do?

# ntpdate pool.ntp.org
ntpdate[573]: adjust time server 45.127.112.2 offset 0.001907 sec
# ntpdate 104.236.52.16
ntpdate[645]: no server suitable for synchronization found

NAT FTW

Just add NAT! Only instead of creating an incoming NAT rule from the WAN as your are accustomed to doing, you will instead redirect all outgoing NTP traffic to the IP address of the firewall (or other internal NTP server of your choice). You can also use 127.0.0.1, which basically tells your firewall to redirect to itself. These are the steps to create NTP NAT rules on a pfSense, but this should work for nearly any firewall.

For pfSense, go to Firewall -> NAT and then Add (Up arrow). Type in the info similar to what you see below.

Once you hit save, you will go back to the NAT page. Make sure your rule is at the top and hit ‘Apply.’

Next, go to Firewall -> Rules and then select your interface (such as LAN). The firewall rule will be automatically created by the NAT addition, but you will need to move the firewall rule up. You could move it to the top, but if you happen to have an ‘allow all’ rule then you *should* at least need to make sure it is above that rule. Note: If your ‘allow all’ rule is above the NTP rule, your NTP redirection would still work. However, you should get used to ordering rules properly. In addition, you won’t see the counters on the left-hand side of the rule increment, which are great to help you easily determine if it is working.

What you will end up with is something like what you see below. Make sure you hit Save!

After NAT rules

A quick retest trying to sync time against the previously blocked IP will provide a little different result this time around because the traffic is redirected to your firewall instead of the actual IP address.

# ntpdate 104.236.52.16
ntpdate[3834]: adjust time server 104.236.52.16 offset 0.000794 sec

One more thing

Only add this rule if you need at least one system on your local network to access an outside NTP server. I use Nagios heavily to monitor my environments. One of my standard Nagios checks is to check a system against an outside NTP server. After all, what good is it to test all of your time against one server and one server only? The above NAT rule would break this functionality that otherwise verifies my system times are not only synced, but correct.

The way to get around this is to create an alias and an invert rule. The resulting NAT rule only works when the destination address is not time.google.com. For example, if a system on that segment tries to access pool.ntp.org, it will receive it’s time from the firewall because of the redirection/NAT rule.

First, create an alias for the NTP servers you want to query directly . Once again, in my case, I only plan to bypass the previously created rule when querying time.google.com. To create the alias, go to Firewall -> Aliases and click “Add” as you normally would. I’ve named my rule TimeGoogleCom, but you can name your alias anything.

Go to Firewall -> Nat and then Add (Up arrow). You would select all the same same options as above with the exception of the destination line (highlighted). You would need to check “Invert match,” select “Single host or alias” and then type in your alias. If you want to further limit which systems can perform this check, you could add an individual IP address or alias in your source address for this rule.

I created a separate NAT rule for another VLAN segment so you can see how the LAN rule is different from it. The alias is clearly listed, but it also has the exclamation point to show it as a “not” (inverted) statement. Don’t forget that you still need the corresponding firewall rule above other rules that could potentially break it!

Testing the additional NAT rule for TimeGoogleCom (time.google.com)

I ran a package capture on the WAN interface while running the ntpdate command against the CentOS pool and then time.google.com. Notice only the packets to time.google.com were sent out the WAN because the other port 123 (NTP) traffic never left the firewall. Super simple, yet ridiculously effective!

# ntpdate 3.centos.pool.ntp.org
ntpdate[10060]: adjust time server 208.75.89.4 offset 0.000389 sec
# ntpdate time.google.com
ntpdate[10126]: adjust time server 216.239.35.4 offset 0.001197 sec