Earlier this afternoon, I just got my new CRS305. I am not using it as a router, just a fancy switch, as such my firewall is empty. I enabled NTP client, and after a few minutes I got syncronized:
Then, I enabled the NTP server. However, I can’t get it to pick up a connection from it. The port seems closed:
$ nmap 192.168.1.88 -p 22,80,123
Starting Nmap 7.93 ( https://nmap.org ) at 2024-07-18 23:29 EDT
Nmap scan report for 192.168.1.88
Host is up (0.00037s latency).
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
123/tcp closed ntp
Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds
$ ntpq -p 192.168.1.88
***Request timed out
$
What other configuration am I missing so I can query the NTP server?
I tried adding some of the input or nat rules from other discussions on this form, and I’ve scoured https://help.mikrotik.com/docs/display/ROS/NTP too, but nothing seems to help open port 123
NTP is a UDP protocol; nmap’s default TCP port scan is correct to show it closed.
While there is a UDP port-scanning option, I’d prefer a tool like ntpdate -q for testing availability. Your own choice of ntpq should also work, though lacking experience with it, I cannot reassure you with an endorsement.
I enabled the NTP server
Verify that with “/system/ntp/server/print”.
Also verify that the IP (192.168.1.88) is correct and that it’s reachable from your network. Have you merely misread the default of 192.168.88.1, transposing the last two octets? Changing the switch’s IP is fine, but please reassure me: is that what you’ve done?
What other configuration am I missing so I can query the NTP server?
You should need nothing else. I have a CRS328 successfully operating in much the same mode as you want your CRS305 to.
The only thing I’d suggest after getting this set up is to declare availability of this internal NTP server of yours using your local DHCP server so that all clients pick it up automatically.
I tried adding some of the input or nat rules from other discussions on this form
You can’t have it both ways. A smart-switch config with no firewall is incompatible with the idea of input filters and NAT. These last will either be ignored, or you’ll end up turning the device into an underpowered router to make them function.
Stick with your smart-switch idea. “/ip/firewall/export” should give nothing but comments for output.
I disagree … one can have firewall rules on a smart switch. But they should only be in chain=input and chain=output. These two chains only affect traffic which is targeting IP stack of switch itself (i.e. management, NTP if you configure it as NTP server for LAN) or switch itself is creating (e.g. NTP client).
For a good measure add single rule for chain=forward:
/ip/firewall/filter
add chain=forward action=drop
This makes sure that switch won’t act as L3 gateway/router, it’ll drop all traffic which merely passes device on L3.
However, I agree that for smart switch one should not need any firewall rules, the default gateway should do the filtering and NAT. Specially so if one configures dedicated VLAN for management and default gateway does the firewalling also for this VLAN (against “normal” LAN).
But only the later method (software IP firewall) offers the benefits of having stateful firewall which IMO outweighs the performance hit … specially when it comes to using it only to control traffic to/from the device itself and thus doesn’t affect traffic passing via the device (on ethernet layer none the less; the former two methods may affect that traffic as well).
What I recommend is… like an AP/switch setup.
One vlan needs to be identified ( the vlan where the switch gets its own IP address), and this should be the trusted or base or management vlan.
Note this assumes that the NTP server is the upstream router ( like the upstream Mikrotik router).
Important settings
Assume management vlan99 192.168.99.0/24 and your switch is assigned 192.168.99.9/24
You’ve apparently got the minimalist “ntpsec” version of these tools installed. I had in mind the more mainstream ntp.org ones, which give more readable output. For reference, here is its output when run against my properly-functioning CRS328’s NTP server, with the debug flag (-d) for extra fun:
Note the “leap” flag is 00, and the offset values small but nonzero.
freq-drift: 0 PPM
That’s difficult to believe. An RTC with under 1ppm drift over a reasonable temp range is expensive, to the point that I’d expect adding such an IC and suitable-quality support parts to double the end-user cost of some RouterOS devices. A result like that makes me wonder if you’re getting the truth from your NTP source.
This in turn makes me suggest switching to different NTP pools. I prefer using the regional pool nearest the end-use location to reduce the pool service’s workload selecting a “nearby” server.
NTP hates step-changes. It is specifically engineered to slew slowly forward in time, only, always. If you start off far enough out of sync, it can indeed take days to get in sync.