 Obtaining time through firewalls Distributing time successfully within your network Personal firewall configuration Allowing remote control/installation or other advanced featuresThis document requires a working knowledge of network principles and operation, as well as familiarity with configuring operating systems in a networked environment. Networks are assumed to be correctly configured with working physical layers, TCP/IP communications, name resolution via DNS and WINS, correctly configured and fully-operational Windows Networking such as proper Windows domain structures and trusts, working Active Directory, etc. Configuration of these items are beyond the scope of this document. Consult your network and/or firewall administrators for assistance as required. Obtaining time through firewalls Domain Time II can obtain the time from any trusted time source, either from the Internet or from local sources such as cesium clocks and GPS systems that provide a network time protocol. The more reliable the time source, the better. Domain Time II contains tools to help you determine the reliability of your time source - see the DT Test and NTPCheck utilities.
 to obtain correct time, such as systems using GPS clock cards, cesium clocks, or other time servers on the network.
 proxies or plug gateways for the time protocols. In addition, Domain Time II provides the unique ability to obtain time through firewalls using existing web proxies or plug gateways using the Domain Time II over HTTP protocol on the well-known HTTP port 80. Pass-thru gateways on port 80, and most proxies that honor immediate page update requests, should work correctly (although accuracy can suffer somewhat if the proxy adds significant delays to the web traffic). Note: Due to the additional overhead and lesser latency correction, this protocol should only be used if you are unable to open your firewall to use the standard time protocols mentioned above (i.e. DT2, NTP, TIME ITP, ect.). Domain Time II also supports SOCKS4 proxies for the Domain Time II over HTTP protocol. Note: Some caching web proxies may be configured in a manner that may not pass along the information Domain Time II requires in a timely enough manner to be used reliably, or performance may suffer unduly under heavy traffic. Thus, trial and error is the only way to determine if any individual proxy will be suitable.
 Time can also be obtained through firewalls that have an existing Web proxy. The Domain Time II Server and Domain Time II Clients employ sophisticated network latency analysis and clock timing adjustment methods to ensure that both the time received and time served are as accurate as possible on every machine on the network (an entire domain, including remote sites over WAN links, can often be held to an variance of less than 100 milliseconds using Domain Time II protocols).
 Using Domain Time II's exclusive HTTP feature, time can be obtained through many existing web proxies with no changes to the firewall. Distributing time successfully within your network Simple networks with a single subnet have very few firewall issues beyond those discussed above in obtaining time or those discussed in the Personal firewall section below. However, more complicated network topologies with multiple subnets can present obstacles to passing the necessary traffic to synchronize time and to pass the Domain Time II control messages used to manage the Domain Time II hierarchy. Any routers or switches used to segment the network should be configured to pass traffic to/from the Domain Time II port 9909 UDP. Traffic should be passed bi-directionally, since traffic may originate from any Domain Time II components to/from any subnet. Domain Time components use Winsock standards for TCP/IP communication and thus typically use ephemeral source ports sending to fixed destination ports. Domain Time II components also use the standard Winsock methods of host name resolution. If you will be synchronizing using other time protocols such as NTP across routers or switches, you will need to pass those protocols as well. See the Time Protocols page for more specific info on the various time protocols.
Broadcast Traffic Stateful firewalls/routers will often require additional configuration to ensure broadcast discovery operates correctly, since unlike normal unicast UDP communication, the originating traffic is not sent to the same IP address from which the reply will come. Broadcast traffic is sent to the address xxx.xxx.xxx.255, but the unicast replies from that subnet may come from any (or all) addresses in the range xxx.xxx.xxx.1-254. Normal stateful firewall rules typically only open the firewall for replies from the same IP address to which the originating traffic was sent, so even if unicast port 9909 UDP traffic is enabled and working, broadcast traffic may still fail. Therefore, most firewalls have special rules that can be applied to allow broadcasts to function correctly, (such as ip helper-address, ip directed-broadcast and ip forward-port functions on Cisco equipment, for example). Check with your firewall manufacturer for the correct broadcast address configuration instructions for your particular systems. See Working across subnets for more information on configuring Domain Time II to work across subnets.
Personal firewall configuration Many individual machines have personal firewall products installed. These products can interfere with the proper operation of Domain Time unless they are correctly configured. Personal firewalls should be configured to pass the same protocols as used on the general network, i.e. especially port 9909 UDP for Domain Time II time and control protocols. Any other time protocols to be used should also be enabled, such as NTP (123 UDP). Particularly, Windows XP/2003/Vista/Win7/2008/Win8/2012 systems have a built-in firewall that needs to be configured to pass the correct protocols if it is enabled. An exemption for port 9909 UDP should be entered. To make this change
Allowing remote control/installation or other advanced features Domain Time II offers the ability to remotely install/upgrade/remove or remotely control Domain Time components on other systems. This is done either from the command-line on certain utilities or by using programs such as Domain Time II Manager. Other Domain Time II programs such as Audit Server have the ability to perform advanced features like remote log collection, adding machines that synchronize with Domain Time II servers to the Audit List automatically, etc. These features require additional network access beyond the communication over port 9909 UDP described above. In general, these functions require the following three functions to work correctly across subnets:
See KB 2001.728 from our knowledgebase for more detailed information on the necessary access for remote control/advanced feature operation. Useful links Microsoft TCP/IP Host Name Resolution Order TCP/IP Client (Ephemeral) Ports and Client/Server Application Port Use Broadcasts And The IP Helper-Address Command Cisco Broadcast Helper Addresses |
