NTP server configuration

byteit101 · Fri Jul 19, 2024 6:47 am

I'm stumped. I've found lots of forums posts about this, such as viewtopic.php?t=203727 or viewtopic.php?p=794718 but none have helped me.

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:

[admin@MikroTik Media] > /system ntp client print
         enabled: yes
            mode: unicast
         servers: 0.debian.pool.ntp.org,1.debian.pool.ntp.org,2.debian.pool.ntp.org,3.debian.pool.ntp.org
             vrf: main
      freq-drift: 0 PPM
          status: synchronized
   synced-server: 2.debian.pool.ntp.org
  synced-stratum: 2
   system-offset: -423.424 ms
[admin@MikroTik Media] >

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

Fri Jul 19, 2024 7:29 am

123/tcp closed ntp

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.

mkx · Fri Jul 19, 2024 8:37 am

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.

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).

Fri Jul 19, 2024 8:54 am

It was more the NAT I was reacting to, but sure, we’re singing from the same hymn book, mkx.

But if I wanted input firewalling on a CRS305, I’d reach for bridge filters first, switch rules second, and the software IP firewall last.

mkx · Fri Jul 19, 2024 9:00 am

It was more the NAT I was reacting to, but sure, we’re singing from the same hymn book, mkx.

But if I wanted input firewalling on a CRS305, I’d reach for bridge filters first, switch rules second, and the software IP firewall last.

You're right from performance point of view.

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).

anav · Fri Jul 19, 2024 5:15 pm

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

/interface vlan
add interface=bridge name=VLAN99 vlan-ids=99

/interface list
add name=MANAGE

/ip neighbor discovery-settings
set discover-interface-list=MANAGE

/interface list member
add interface=VLAN99 list=MANAGE

/ip address
add address=192.168.99.9/24 interface=VLAN99 network=192.168.99.0

/ip dns
set servers=192.168.99.1

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.99.1

/system ntp client
set enabled=yes
/system ntp client servers
add address=192.168.99.1

/tool mac-server
set allowed-interface-list=NONE
/tool mac-server mac-winbox
set allowed-interface-list=MANAGE

byteit101 · Sun Jul 21, 2024 11:30 pm

NTP is a UDP protocol; nmap's default TCP port scan is correct to show it closed.

Whoops, I knew that but forgot to have nmap do that.

123/udp open ntp

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.

Hmm, that does give better error messages:

$ sudo ntpdate -q 192.168.1.88
ntpdig: 192.168.1.88: Response dropped: leap not in sync
ntpdig: no eligible servers
$

Huh, I'm still in sync:

[admin@MikroTik Media] > /system/ntp/client/print
         enabled: yes
            mode: unicast
         servers: 0.debian.pool.ntp.org,1.debian.pool.ntp.org,2.debian.pool.ntp.org,3.debian.pool.ntp.org
             vrf: main
      freq-drift: 0 PPM
          status: synchronized
   synced-server: 2.debian.pool.ntp.org
  synced-stratum: 2
   system-offset: 8.745 ms
[admin@MikroTik Media] >

Verify that with "/system/ntp/server/print".

Looks reasonable?

[admin@MikroTik Media] > /system/ntp/server/print
              enabled: yes
            broadcast: no
            multicast: yes
             manycast: yes
  broadcast-addresses: 
                  vrf: main
      use-local-clock: no
  local-clock-stratum: 5
             auth-key: none
[admin@MikroTik Media] >

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?

Yes, I did change the IP address to my local network.

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 already did that. In fact, I saw that option in DHCP, and that is what kicked off my attempt to use NTP

Dropping the firewall rules results in no change. I have rebooted, and that also made no change

Mon Jul 22, 2024 8:02 pm

ntpdate -q
Hmm, that does give better error messages:

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:

22 Jul 10:49:50 ntpdate[67301]: ntpdate 4.2.8p18@1.4062-o  Sat May 25 07:06:58 UTC 2024 (1)
…
stratum 3, precision -20, leap 00, trust 000
refid [129.146.193.200], root delay 0.094711, root dispersion 0.028885
reference time:      ea48f371.55e9da82  Mon, Jul 22 2024  9:04:17.335
originate timestamp: ea490c2e.ed592d98  Mon, Jul 22 2024 10:49:50.927
transmit timestamp:  ea490c2e.d7acc4f0  Mon, Jul 22 2024 10:49:50.842
delay 0.02600, dispersion 0.00000, offset +0.084362

22 Jul 10:49:50 ntpdate[67301]: adjust time server 192.168.88.1 offset +0.084362 sec

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.

byteit101 · Tue Jul 23, 2024 6:34 pm

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.

Ah, looks like the "mainstream" ones are deprecated, so Debian replaced them with ntpsec.

Either way, both tools are now working. The only thing I did was leave the switch running?

Tue Jul 23, 2024 11:44 pm

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.

NTP server configuration [SOLVED]

NTP server configuration

Re: NTP server configuration

Re: NTP server configuration

Re: NTP server configuration

Re: NTP server configuration

Re: NTP server configuration

Re: NTP server configuration

Re: NTP server configuration

Re: NTP server configuration

Re: NTP server configuration [SOLVED]

Who is online