My ISP has blocked port 123. I do not expect them to remove the block. Is there a simple, low-cost way to get time to the router?
You don’t say which device you have. If it’s a MAX series you may be able to get it via GPS signal (using recent firmware.) “There’s a setting for that.”
But I’m finding it challenging to understand why any – any – ISP would block port 123. Makes no sense. I guess you are certain about that?
I have the Surf SOHO MK3. I posted on the “Pepwave AP & Surf” product discussion section so I thought it was understood. But will update my topic to avoid any ambiguity. The reason it is blocked is because the ISP is concerned about DDoS attacks. I had filed a ticket with Pepwave a while back and a tech logged on the router and was able to confirm it.
Here is a link to a more detailed description than I can give you…
I have had no responses from anyone other than you so I assume that no one has any ideas since my post from a week ago. My understanding is that there are several ISPs that have the same policy so this should not be a rare situation. The time does not need to be very accurate. If there is a way that a computer on the LAN side can provide the time can the router accept it from that source? I have looked into that possibility but all the programs I have found depend on port 123. (I am running Debian Linux.)
Hi. Still seems bizarre that an ISP would block NTP. But I’ll certainly take your word for it!
We have used products from Leo Bodnar and Time Machines for Stratum 1 time servers when we can’t or don’t’ want to get to 'net-based servers. And, you could certainly upgrade your SOHO to one of the MAX series with GPS.
Without adding equipment to your network I am not aware of a way to get time syncs. However, I’ll invite comments from others.
The easiest way to probably get around the block from your ISP is to setup a Fusionhub on a solo license on Vultr for $5/month. FusionHub has a built in NTP server, so you can route all NTP traffic over the PepVPN, and since its a cloud server, its bypassing your ISP.
I would follow @MartinLangmaid’s video here if you want to test that method. Setting Up SpeedFusion between a FusionHub On Vultr and a Peplink BR1 4G Router - YouTube
Thank you very much for your suggestion. I have no need to any of the other functions for the FusionHub and it would be a recurring $5/month cost that would add up to where I could make a one time purchase of a hardware time server. Granted $5/month is not much but if there was a manual way to set the time from the router web GUI from the wall clock that would be all it would take to make me happy. My needs for the router are not extensive. I tested a basically simple solution I thought should work using a NTP server from the LAN side but it didn’t. However, I don’t know if NTP data can be accepted from the LAN side. I wish someone could answer that question.
I don’t see why NTP couldn’t be accepted from a LAN device. I don’t have a SOHO device, but I assume it has atleast 1 of these two options listed below should work with what you have just tried. Setup your LAN device as NTP server, give static IP address.
Network → Misc. Settings → Service Forwarding - under “Custom Service Forwarding” settings redirect all NTP traffic (ie: port 123) to the specific LAN address of your NTP server.
Additionally, you can adjust the “Internal Network Firewall Rules” to force redirection of all port 123 traffic to your specific NTP server.
That is a pretty horrible solution on the part of your ISP, NTP is a critical protocol for a lot of devices and particularly more so today given the growing number of IOT / Smart Home appliances that rely on accurate timing information to function - my light bulbs rely on setting their clocks accurately via NTP for example to turn on and off on schedule!
I would press them hard on this, either to remove the outbound port 123 block or to provide access to an NTP server within their network that you could tell your Peplink to use (the Peplink in turn can be configured to act as an NTP server for other devices behind it if necessary).
Does your ISP also block all outbound SMTP traffic on port 25 “because of spam” or filter all DNS outbound on port 53 via their own recursors “because of DNS amplification attacks” - strikes me they could use a few lessons in technical competence in how to effectively mitigate DDoS attacks both as a victim and an (unwilling) participant…
If I were in your position the $5 a month to tunnel all my traffic elsewhere would be an attractive option given the questionable policies of your ISP it makes you wonder what other traffic they may be messing with, we have also used the Leo Bodnar appliances and they are good for the money although perhaps overkill for your needs.
One suggestion is that you could run a time server within your network (a raspberry pi or any linux box would do) and enter that as the timeserver for your router.
Normally that wouldn’t help, but since, as you said, the time doesn’t need to be very accurate, you can set the device to poll a time source that isn’t NTP, eg: header “date” fields
(blatently stolen from this askubuntu article )
sudo date -s “$(wget -qSO- --max-redirect=0 18.104.22.168 2>&1 | grep Date: | cut -d’ ’ -f5-8)Z”
Wrap it up in a cronjob to poll periodically to handle clock drift, and then set the device to act as an NTP server, and you should be good.
Yes, that is something that I have considered. Thank you! I have been researching how to use chrony as an NTP server to the Pepwave. It does allow manual time setting via keyboard. https://chrony.tuxfamily.org/ I am assuming that should work from my destop computer. Community member “Cable17” gave me a couple of things to consider as part of what to do to make that work. Thank you too! The gpsd daemon may be another way. GPSd — Put your GPS on the net! But their GPS list is dated and several of the better ones I looked into were no longer available. I am going to try again with the ISP to see if they can make an exception.
hmm, or… well, apparently nist DOES still run time / daytime services, so you could just install rdate on your system, open port 37 on your firewall, and have a root cronjob periodically run:
nist works for me. Thank you! I can make it all go together with the cronjob you mention. Although the nist web site mentions that people should move to a standard NTP source. So nist may not last long. I did get chrony to work as an NTP server. I had expected the SOHO to respond via source port 123 but it uses another port. I think that chrony may use a different source port as well. My ISP has responded that they only block the source port 123 but not the destination. If there are any NTP servers out there that do not use port 123 as the source that would be good. The NTP server lists that I have found never list their source port and I don’t know any easy way to figure out which ones don’t other than trying them one by one.
That is because the source port is chosen by your client device when it makes the initial request, not by the server. The source port may be randomised, or may be fixed as UDP 123 depending on the exact application and behaviour of the device.
Your Peplink is also performing PAT on your traffic for internal devices, so may further randomise the source port when a packet passes through it, for instance 2 internal devices trying to connect to the same external IP using UDP123 the Peplink would need to perform PAT on one packet to use a different outbound source port. What the Peplink does for its own requests though (quite likely is using a fixed outbound port and as is possibly sourcing it directly from your WAN interface so there is no PAT happening).
To illustrate this I just grabbed the traffic logs from my firewall (a Fortigate) for the last couple of hours, as you can see many devices are sending NTP queries to many different destinations. In some instances the source port is UDP 123, in some instances it is randomised, in some instances my firewall has further randomised the port actually used for the connection (device sent on UDP 123, firewall randomised it -NAT Source Port).
You say you have Chrony working, you could try to install NTPD on a Linux machine and use some iptables rules to mangle the outbound port used for NTP requests to a randomised one (i.e. not UDP 123) and that in theory would get NTP working, you could then tell your Peplink to sync its time from that machine.
Thank you for your response. You have made me smarter. Chrony seems to have worked well so far. But I will save your response for the future in case that I need more precise time.