The new NAT engine in V18 provides a high degree of flexibility when it comes to solving some interesting network problems. I don't know if it has been shared here or not, but you can use NAT to achieve NTP proxy like functionality. A standard use case seen is that clients would like to use the IP address of the firewall as the NTP server. Consider this as an example environment:
There are two different approaches to a transparent NTP solution.
1.: NTP should be forwarded to a particular externally(WAN) host/host group.
2.:NTP should be forwarded to a own ressource within the network and this server should provide the information.
First scenario is rather simple.
You need one NAT Rule, which translate everything NTP based to a particular host.
You can specify all internal hosts with "Interface matching criteria - Inbound Interfaces". This example shows ANY. You can select all internal network interfaces (expect WAN).
This rule will fetch all NTP related traffic, forward it to a public NTP service and use MASQ. MASQ is required for WAN related traffic.
You need a firewall rule:
You can attach IPS rules to this, if you want.Build your own NTP rule, with all NTP related IPS pattern.
Regardless of the configured IP on a client behind Sophos Firewall, the NTP request will work.(Example: 184.108.40.206)
Second scenario needs more rules, as you can easily generate a NTP loop. Your internal server need a own NAT rule and own firewall rule. Example = Windows2016 is a NTP server.
NAT Rule 1# NTP Server to WAN (to get the NTP server to the WAN NTP servers.)You can also force the internal NTP server to get the IP from a particular NTP pool, but we assume, the NTP server has his own NTP request pool.
NAT 2# It will forward the NTP traffic transparent to the internal NTP server.
Firewall rule #1Allowing the traffic of the NTP server to the WAN to get current time.
Firewall rule #2Allowing the Traffic from all internal clients to the internal NTP server. Notice the destination zone.
Naturally, you can create variations of this NAT policy, based on your network configuration and the location of the NTP server.
In the new XG V18 architecture training course, there are a few more examples demonstrating how to control NTP and DNS traffic. I encourage you to check out the training material as it provides more in-depth knowledge of the new V18 features.
I voted, like the other 665 administrators, to implement the NTP server in the XG Firewall. Unfortunately, even though the NTP server is the second most demanded feature at the ideas.sophos…
Thanks for the nice idea. Missing the NTP and also voted for it. But for now it works as a hack. As the last comment was from 2017 I won't suppose that it will be implemented as a feature like many other things competitors can. See fixed IPs for SSL VPN...
That assumes you are using an external NTP service, if you are trying to use an internal server then that does not work, neither does the hairpin NAT.
I don't understand what you want to say to me. I (and everyone else here) want to use the XG as a NTP service internally. But the XG doesn't have this feature. So the idea is to forward NTP requests which are sent to the XG address to an external service which works like described here. The internal devices don't know that they are forwarded...
what I was pointing out is that I have tried all those ideas and a hairpin NAT and not all devices were happy with the result, hence I built my own internal NTP server.
Which device didn't work for you? I had several devices yesterday which I tested and everyone worked:
- Windows Server
- Unify X8
What error do you get while using it on the faulty device?
One of my IoT devices kept trying to connect to a Chinese university helpdesk, the manufacturer could not help and did not understand. I have set up the NTP access rules again and this time the FQDN group is working and limiting access to NTP servers only.
So you had traffic on udp/tcp 123 for other reasons than NTP as far as I understood? Good point, didn't think about that to restrict it further.
it is a bug inn the device that the manufacturers say does not exist. When the XG NAT is working the devices connects to the NTP internal server, it only tries to connect other Chinese site when the XG decided to block the NTP traffic. Sine then after much experimentation I have the hairpin firewall rule and NAT working for most connection attempts enough so that the internal devices all talk to the NTP server. There are still issues where the XG decides that it will double NAT some traffic and appears to also corrupt some traffic. v18.0.5 mr-5 has an undocumented partial fix for the hairpin NAT issue.
Before MR-5 the NAT would fail and require a configuration changes to restore the service, after MR-5 the issue is no longer apparent. The issue is reproducible.