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:
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:
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:
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):
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:
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:
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):
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.deCapturing 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):
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: 0ea89c97468d448bc88a4f16dbb02f00In the end, this was my NTP config on this ScreenOS device:
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.