12-20-2016 7:19 AM
I have a Pace 5268AC and have my own router behind it using DMZplus. The firmwware is versions are:
I can't get any devices to sync time using NTP. This includes laptops, desktops, Raspberry Pis and other devices. This is causing me no end of issues as with devices so far out of sync SSL certs fail checks, services on Linux boxes hang etc.
I have searched everywhere and found references to others having issues but haven't found any soltuions. I have tried factory resetting the 5268AC and tried adjusting the "Strict UDP Session Control" setting in the Advanced firewall tab.
I find it hard to accept that no gigapower users are allowed to sync time, am I missing something? Is this a bug in the 5268AC? Any help would be very much appreciated.
12-20-2016 7:40 AM
First, I'm curious: your title says that the 5268ac is blocking NTP. Any reason that you picked the 5268ac as the offending device (as opposed to something else in the AT&T network)?
I am using NTP at home without observing any issue. However, I have seen an article that said AT&T blocked NTP in its network. Given that I know my client access works, and that many, many others need NTP, I cannot accept that statement at face value. They may mean that requests into end user networks are blocked, i.e. you should be able to access an NTP server from your network, but that no one could access an NTP server that you were running.
Maybe @ATTU-verseCare can expound upon this issue for us.
12-20-2016 7:57 AM
Hey, thanks for the response.
You are correct that AT&T could be blocking NTP elsewhere. I imagine this would be a big problem though, it would break every device and service that needed accurate time to function correctly. I just assumed that wasn't the case.
The use case you are describing is what I desire, I want to be able to access NTP servers from my network but have no need for anyone to be able to access a NTP server on my network.
Easy use case example: Windows laptops & desktops can't sync time with time.windows.com. I need them to be able to.
How are you sucessfully using NTP?
- edited 12-20-2016 4:08 PM
I'm not sure why we're different, I just know that I am getting NTP responses; my time server just checked in 4 hours ago. Maybe only a list of published NTP servers are whitelisted for NTP traffic? BTW, I've had issues with time.windows.com. I usually use some other public NTP server. You can find one at http://www.pool.ntp.org/en/ . The NIST also has public NTP servers, and the DNS name time.nist.gov will cycle through them. Try accessing one of these NTP servers and see if you have more luck.
It sure would be nice if @ATTU-verseCare could get us some answers here.
12-20-2016 4:15 PM
Agree time.windows.com can be a bit unreliable. It was just an example though to illustrate the impact.
I have tried pool.ntp.org, the debian pool (basically the same thing) as well as a few others, however I will give time.nist.gov a shot as well.
Perhaps @ATTU-verseCare will enlighten us. I would love for this to be a simple setting or error on my part.
12-26-2016 8:23 AM
So I have done more work on this (AT&T hasn't responded to anything here or in the help request I submitted...).
AT&T does drop any UDP traffic with a source port of UDP 123 (NTP), this could be happening at the gateway or in the network, doesn't matter the traffic gets dropped. If your firewall is passing the traffic without mapping the source traffic to a different port then your not going to be able to sync time across the Internet unless your NTP client itself uses a non UDP 123 port. For Windows, OS X and Linux (using NTPD, openntpd uses a random port) this means you won't be able to sync time at all. This could break IoT devices as well and those may or may not offer a way to mannually set the time.
Now if your firewall can do outbound NAT / masqurading at the IP and port level then you're golden. In my case I replaced my router with a pfSense install which does this by default to test this and everything started working. All I had to do was tell pfSense to only run NTP on the LAN (by default it runs it on all interfaces) so the firewall itself could sync time. So for now I am back on pfSense as my firewall solution.
Also a note: My configuration has my 5268AC in DMZplus (aka bridge) mode. This may or may not acutally be a problem for folks who are using the 5268AC as their gateway and router (non DMZplus mode). In non DMZplus mode the 5268AC may do this masquarding itself.
12-27-2016 10:27 AM
12-27-2016 10:34 AM
I have used NTP through the 2WIRE 3800 Gateway with and without my ASUS Router in line, and yes, I have it in DMZplus mode.
01-03-2017 7:00 AM
We apologize for the inconvenience with port 123 block policy for NTP. Visit this site for more information on why certain ports like port 123 are blocked on the AT&T network.
01-03-2017 10:55 AM
So... does AT&T provide access to unblocked NTP services? Using a sledgehammer to drive a 2-penny nail is rather silly. Perhaps you could consider simply filtering out by frequency and/or content?
01-10-2017 12:37 PM
I have the same device in DMZPlus mode and I called AT&T about the issue. I have plenty of other firewalls on the AT&T network, and no other devices are unable to access NTP servers. I also attempted to use ntp.sbcglobal.com and ntp1.sbcglobal.com, which also fail to work. I was told by support to allow "NTP" in the firewall settings on the Pace - when she first said it, she said "NNTP" and I said "do you mean NTP?" and she said "yes, NTP." NNTP is an option on the Pace, NTP is not. There is no reason not to allow NTP, that baloney posted by @ATTU-verseCare aside, and if you do block it, you should provide NTP servers of your own, although that is a terrible solution.
AT&T came out and replaced our original modem with this device, and now we are connected to a broken network. AT&T needs to fix this ASAP.
01-10-2017 1:45 PM
As silly as it appears to you and me, AT&T has documented on their support pages that they block UDP 123 as an anti-DDoS practice. For some reason my system has no trouble getting to the NTP servers I use. If that changes, I will have to reluctantly reconsider my Internet Service Provider.
01-10-2017 7:55 PM
It's important to note they are blocking source traffic on UDP 123... not destination.
If your firewall does port level masquarding (like pfSense does) then your network will be able to access NTP services because the source traffic from you won't be on UDP 123, it will be on some randomized port.
On Linux systems it is easy to see this by using ntpdate to sync the time, this NTP client will work because ntpdate (and apparently openntpd) use a random unprivileged port (> 1024) to connect to NTP servers. But if you use NTPD it which uses a source port of UDP 123 it will fail.
So if you currently can't access NTP servers check to see if your firewall can masquarde at the port level.
- edited 01-11-2017 5:59 AM
Ah. Good point! I'm sure my NTP usage doesn't involve a source port of 123. Is there some particular reason to use symmetric mode vs. asymmetric mode NTP? I picture symmetric mode for use by a farm of servers on a LAN that share responsibility as a time source, and asymmetric mode for nearly every other use.
Visit these related resourcesView New Device Help!