Yes, ScreenOS is end-of-everything (EoE), but for historical reasons I still have some of them in my lab. ;D They simply work, while having lots of features when it comes to IPv6 such as DHCPv6-PD. However, using IPv6-only NTP servers is beyond their possibilities. :(
Anyway, I tried using NTP authentication with legacy IP. Unfortunately, I had some issues with it. Not only that they don’t support SHA-1 but MD5, this MD5 key was also limited in its length to 16 characters. Strange, since ntp-keygen per default generates 20 ASCII characters per key. Let’s have a look:
I am using an SSG 5 with firmware version 6.3.0r20.0.
IPv6: Configurable but Failing
Entering an IPv6-only NTP server at Configuration -> Date/Time is possible without any errors:
However, having a deeper look reveals that it is not working at all since it tries to connect to an IPv4 address of 0.0.0.0 rather than the actual IPv6 address:
1 2 3 4 5 6 7 8 9 |
IPv6-Lab-> debug ntp detail IPv6-Lab-> get db stream ## 2019-03-26 16:25:18 : NTP registers DNS for ntp3.weberlab.de. ## 2019-03-26 16:25:23 : NTP:Auto Update: START ## 2019-03-26 16:25:23 : NTP:[sock 79]: sendto() ret -10995, dest_ip 0.0.0.0, ifp default ## 2019-03-26 16:25:23 : ntp_task: try next from ntp task ## 2019-03-26 16:25:23 : NTP:[sock 79]: sendto() ret -10995, dest_ip 0.0.0.0, ifp default ## 2019-03-26 16:25:23 : ntp_task: try next from ntp task ## 2019-03-26 16:25:23 : NTP:[sock 79]: sendto() ret -10995, dest_ip 0.0.0.0, ifp default |
Note that, for whatever reason, the debug command “debug ntp detail” is NOT documented. ;D Neither on the official docs nor in the CLI when using the question mark. Strange.
NTP Auth with Legacy IP Failing As Well
Ok, at first I configured an NTP server with legacy IP, but yet without authentication, which has worked correctly:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
IPv6-Lab-> get db stream ## 2019-03-26 16:26:46 : NTP registers DNS for ntp3-v4.weberlab.de. ## 2019-03-26 16:27:23 : NTP:Auto Update: START ## 2019-03-26 16:27:23 : NTP:[sock 79]: sendto() ret 0, dest_ip 87.190.30.119, ifp default ## 2019-03-26 16:27:23 : NTP: process_recd: server 87.190.30.119, auth info 0, authed 0 ## 2019-03-26 16:28:24 : NTP:Auto Update: START ## 2019-03-26 16:28:24 : NTP:[sock 79]: sendto() ret 0, dest_ip 87.190.30.119, ifp default ## 2019-03-26 16:28:24 : NTP: process_recd: server 87.190.30.119, auth info 0, authed 0 ## 2019-03-26 16:29:24 : NTP:Auto Update: START ## 2019-03-26 16:29:24 : NTP:[sock 79]: sendto() ret 0, dest_ip 87.190.30.119, ifp default ## 2019-03-26 16:29:24 : NTP: process_recd: server 87.190.30.119, auth info 0, authed 0 ## 2019-03-26 16:30:24 : NTP:Auto Update: START ## 2019-03-26 16:30:24 : NTP:[sock 79]: sendto() ret 0, dest_ip 87.190.30.119, ifp default ## 2019-03-26 16:30:24 : NTP: process_recd: server 87.190.30.119, auth info 0, authed 0 |
Adding MD5 authentication (since I read in the “ScreenOS Cookbook” that it only supports MD5):
Now it became strange. There was no error when configuring this key at the GUI. However, the authentication was not working:
1 2 3 4 5 6 7 8 9 |
IPv6-Lab-> get db stream ## 2019-03-26 16:42:27 : NTP:Auto Update: START ## 2019-03-26 16:42:27 : NTP:[sock 79]: Send: auth keyid 3 ## 2019-03-26 16:42:27 : NTP:[sock 79]: sendto() ret 0, dest_ip 87.190.30.119, ifp default ## 2019-03-26 16:42:27 : ntp_recv_response: Received key-id only (auth will fail) ## 2019-03-26 16:42:27 : ntp_task: try next from ntp task ## 2019-03-26 16:42:27 : NTP:[sock 79]: Send: no key id found for server ## 2019-03-26 16:42:27 : ntp_task: try next from ntp task ## 2019-03-26 16:42:27 : NTP:[sock 79]: Send: no key id found for server |
Capturing with tcpdump on the NTP server itself (not on the SSG) reveals an incoming key ID, while the server responds with “key id: 0” with is the crypto-NAK (line 23), refer to Packet Capture: Network Time Protocol (NTP):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
16:05:30.524531 IP (tos 0x0, ttl 60, id 47648, offset 0, flags [none], proto UDP (17), length 96) p4FE245A7.dip0.t-ipconnect.de.50126 > 192.168.30.3.123: [udp sum ok] NTPv4, length 68 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3762605130.000000000 (2019/03/26 16:05:30) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3762605130.000000000 (2019/03/26 16:05:30) Key id: 50331648 Authentication: 25cc8975d32be499444e29cefad098cb 16:05:30.525143 IP (tos 0xb8, ttl 64, id 51806, offset 0, flags [DF], proto UDP (17), length 80) 192.168.30.3.123 > p4FE245A7.dip0.t-ipconnect.de.50126: [udp sum ok] NTPv4, length 52 Server, Leap indicator: (0), Stratum 1 (primary reference), poll 3 (8s), precision -18 Root Delay: 0.000000, Root dispersion: 0.437576, Reference-ID: PZF^@ Reference Timestamp: 3762605128.036574449 (2019/03/26 16:05:28) Originator Timestamp: 3762605130.000000000 (2019/03/26 16:05:30) Receive Timestamp: 3762605130.524534523 (2019/03/26 16:05:30) Transmit Timestamp: 3762605130.525092899 (2019/03/26 16:05:30) Originator - Receive Timestamp: +0.524534523 Originator - Transmit Timestamp: +0.525092899 Key id: 0 |
MD5 Key Limited to 16 Chars
I tried entering the MD5 key through the CLI which gave me a hunch:
1 2 3 4 |
IPv6-Lab-> set ntp server key-id 4 preshare-key }qcCM:BI|^laK>oL',0& Preshare key cannot be more than 16 characters Failed command - set ntp server key-id 4 preshare-key }qcCM:BI|^laK>oL',0& |
Uh, “Preshare key cannot be more than 16 characters“. I have not seen this information in any kind of documentation. At least the error message tells it. Thanks.
Finally, I generated a 16 character MD5 key on my NTP server (Meinberg M200) which indeed worked:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
IPv6-Lab-> get db stream ## 2019-03-26 17:05:51 : NTP registers DNS for ntp3-v4.weberlab.de. ## 2019-03-26 17:06:30 : NTP:Auto Update: START ## 2019-03-26 17:06:30 : NTP:[sock 79]: Send: auth keyid 10 ## 2019-03-26 17:06:30 : NTP:[sock 79]: sendto() ret 0, dest_ip 87.190.30.119, ifp default ## 2019-03-26 17:06:30 : NTP: process_recd: server 87.190.30.119, auth info 1, authed 0 ## 2019-03-26 17:07:30 : NTP:Auto Update: START ## 2019-03-26 17:07:30 : NTP:[sock 79]: Send: auth keyid 10 ## 2019-03-26 17:07:30 : NTP:[sock 79]: sendto() ret 0, dest_ip 87.190.30.119, ifp default ## 2019-03-26 17:07:30 : NTP: process_recd: server 87.190.30.119, auth info 1, authed 0 ## 2019-03-26 17:08:30 : NTP:Auto Update: START ## 2019-03-26 17:08:30 : NTP:[sock 79]: Send: auth keyid 10 ## 2019-03-26 17:08:30 : NTP:[sock 79]: sendto() ret 0, dest_ip 87.190.30.119, ifp default ## 2019-03-26 17:08:30 : NTP: process_recd: server 87.190.30.119, auth info 1, authed 0 |
Similar log events in the “get event” output (which is also displayed in the GUI):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
IPv6-Lab-> get event Total event entries = 1027 Date Time Module Level Type Description 2019-03-26 17:35:34 system notif 00531 The system clock was updated from primary NTP server type ntp3-v4.weberlab.de with an adjustment of -141 ms. Authentication was Required. Update mode was Automatic 2019-03-26 17:35:34 system notif 00531 The system clock will be changed from 2019-03-26 17:35:34 to 2019-03-26 17: 35:35 received from primary NTP server ntp3-v4.weberlab.de 2019-03-26 17:34:34 system notif 00531 The system clock was updated from primary NTP server type ntp3-v4.weberlab.de with an adjustment of -161 ms. Authentication was Required. Update mode was Automatic 2019-03-26 17:34:34 system notif 00531 The system clock will be changed from 2019-03-26 17:34:34 to 2019-03-26 17: 34:34 received from primary NTP server ntp3-v4.weberlab.de |
Capturing on the NTP server again, you can now see a working NTP authentication since the server replies with the key ID and the MAC (lines 23+24):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
16:06:30.679902 IP (tos 0x0, ttl 60, id 47879, offset 0, flags [none], proto UDP (17), length 96) p4FE245A7.dip0.t-ipconnect.de.50126 > 192.168.30.3.123: [udp sum ok] NTPv4, length 68 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3762605191.000000000 (2019/03/26 16:06:31) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3762605191.000000000 (2019/03/26 16:06:31) Key id: 167772160 Authentication: ddd56ee3c620023ffa7493563c72804d 16:06:30.681187 IP (tos 0xb8, ttl 64, id 54378, offset 0, flags [DF], proto UDP (17), length 96) 192.168.30.3.123 > p4FE245A7.dip0.t-ipconnect.de.50126: [udp sum ok] NTPv4, length 68 Server, Leap indicator: (0), Stratum 1 (primary reference), poll 3 (8s), precision -18 Root Delay: 0.000000, Root dispersion: 0.000228, Reference-ID: PZF^@ Reference Timestamp: 3762605184.036936558 (2019/03/26 16:06:24) Originator Timestamp: 3762605191.000000000 (2019/03/26 16:06:31) Receive Timestamp: 3762605190.679905176 (2019/03/26 16:06:30) Transmit Timestamp: 3762605190.681111216 (2019/03/26 16:06:30) Originator - Receive Timestamp: -0.320094853 Originator - Transmit Timestamp: -0.318888783 Key id: 167772160 Authentication: 0ea89c97468d448bc88a4f16dbb02f00 |
In the end, this was my NTP config on this ScreenOS device:
1 2 3 4 |
set ntp server "ntp3-v4.weberlab.de" set ntp server key-id 10 preshare-key "M1z+bLfrNWxaOos/G1CrNHdySwnDJucDu3zRlFL2oP3nxFqYKTNm7ZM=" set ntp interval 1 set ntp auth "required" |
Ok, hm. I’m not happy at all. However, it’s an outdated firewall anyway, you know. So I don’t bother.
Have a good time! Ciao.
Featured image “rusted boiler#24553” by prof.bizzarro is licensed under CC BY 2.0.