Time Syncing Through a Firewall Without NTP?

dvdsmith asks: "Say are dealing with a Windows network that for internet access must pass through a firewall that you have no control over. Said firewall apparently blocks the known time protocols (NTP,daytime,etc) and you know from experience that those who control it will not allow any exceptions. If one sets up an internal NTP server (Windows XP or 2000 workstation) for all others to sync from, is there another reliable method for updating time on the server, like pulling from a Java website? See the time.gov website as an example. Any ideas?"

Comments

Tunnel.

[SharpFang]

Set up a host outside the firewall, and tunnel the NTP data over some "allowed" port, so it gets through. Or set it up as NTP server on non-standard port (80?) outside the firewall.
If you want precise measurement, this is the way to go. NTP software will correct the latency errors, no matter if you have direct connection or if it goes through tunnels around the globe, so you have precise time. But if you go for methods like reading time from website applet, all the network latency problems get completely neglected and just add up to the error of the internal server. You could just as well sync it to your hand watch instead.

Tunneling

[digitalvengeance]

The most common solution to a firewall blocking a particular port or service: tunnel it. SSH is probably the easiest form of tunneling and putty has a great command line utility for just that. But you can also tunnel over HTTP using some basic programming skills. Worst case: set up a port forwarder on the outside of the network that forwards requests on port 80 to time.gov (or some other trusted NTP server) then set your internal NTP server to sync with it on port 80. (This assumes, of course, port based filtering.)

Two completely untested suggestions

[moreati]

1. Hook up a GPS receiver directly, via the usb/serial port, use whatever software to interface

2. Use HTP: HTTP Time Protocol

"Atomic Clock" card

[SA Stevens]

You can run a local NTP server, and install an 'Atomic Clock' receiver in it, on a Card. Basically it's a 10 MHz WWV receiver that decodes the time info and reads it into the PC. They've been around a long time.

Re:Here's what I'd do...

[secolactico]

Give them a breakdown of costs like so:

$x for GPS stabilised NTP appliance.
$y for some bonehead in IT to open the port up.

And don't forget to include installation costs in the breakdown. Depending on your building infrastructure, you might have to run wiring for an external gps antenna, plus related costs of mounting an outdoor equipment, which will probably be done by the maintenance people or subcontracted.

Re:too easy

[vadim_t]

BAD idea! Don't do that!

Think of it for a while. The HTTP server takes its local date, writes it into a socket, and sends it to you. By the time you get it, the time will have changed. If your time was actually right, it'll go like this:

You (10:00:00): HTTP request
Server (10:00:01): Sends date
You: (10:00:02): Date received, set

And here you set the date backwards in time, which is definitely going to cause problems.

Use a cheap GPS

[Telecommando]

Buy a Delorme Tripmate on Ebay. Buy or build a power/serial cable. Connect pins 2&3 on the serial port so the Tripmate will self start. Parse the ASCII strings sent by the Tripmate. The string you need looks like this:

$GPRMC,HHMMSS,A,LATITUDE,N/S,LONGITUDE,E/W,SPEED,D IRECTION,DDMMYY,MAGNETIC,E/W*CHECKSUM

A search on Google for "Delorme Tripmate" and/or "NMEA-0183" should turn up plenty of info.

I use a Tripmate in my car connected to a Microchip PIC and an LCD to display time, date, location, speed and direction.

Re:You should use NTP

[ComputerSlicer23]

You really shouldn't be so absolute about those things. I've done IP over ssh, which means you can do ICMP, UDP, and TCP over it. Not using ssh and port forwarding, but using ssh, pppd, it can be done. You create a pppd device that is attached to a terminal, the terminal gets created by sshd. You do all the same things at the other end. It's a bit more work on both ends to accomplish it, but anywhere you can do ssh port forwarding, you should be able to tunnel PPP over SSH.

It's standard and fairly simple. You can read about it here

As to why UDP is used, has nothing to do with "faster". The protocol is designed to use UDP, because it's connectionless, it has lower latency, and the TCP connection encapsulates a lot of the properites that NTP measures to correct for latency and transmission delay. If a packet gets dropped via UDP, NTP can compensate for that, with TCP it's much harder. If a packet gets dropped, retransmitting the same one again is stupid (that's what TCP would do), you should transmit a new one with a new timestamp (you can do this via UDP).

Kirby

Is the router an NTP server?

[Webmoth]

Have you checked the obvious? Many routers and firewalls also serve NTP. Try polling NTP on the firewall. It just might work.

If that doesn't work, try polling the local router. Try polling a remote router that's still inside the firewall.

A customer of mine has several sites, and the sites are linked through frame relay (or is it T-1?). The firewall blocks port 123, so NTP with the outside world is (generally) out of the question. However, the frame provider is MCI, who also happens to manage the routers for the customer, and the routers poll NTP from MCI's network, and serve NTP to the local network. Rather handy.