I have a CentOS server on which I want to set up an NTP client to get accurate time for the server. The server is on a local subnet with NAT behind an ASA 5505 firewall, which acts as NAT router, and which in turn directly connects to the internet DSL modem, no other router.
The problem is that the NTP client on the CentOS server just never manages to synchronize with any NTP server I choose. Setting up the ASA 5505 as NTP client works completely fine however. Using the same IP addresses on the CentOS server still gives me no sync, even when waiting for hours.
ntp.conf is:
restrict 127.0.0.1 restrict -6 ::1 server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift keys /etc/ntp/keys server 89.109.251.21 server 176.9.47.150 server 63.15.238.180
Using ntpq tells me that none of these servers are being reached (while at least two of them ARE reachable at any time from the ASA so they are okay):
peers
remote refid st t when poll reach delay offset jitter
*LOCAL(0) .LOCL. 10 l 25 64 377 0.000 0.000 0.001
89.109.251.21 .INIT. 16 u - 1024 0 0.000 0.000 0.000
odin.tuxli.ch .INIT. 16 u - 1024 0 0.000 0.000 0.000
63.15.238.180 .INIT. 16 u - 1024 0 0.000 0.000 0.000
For the moment that shows .INIT. on the refid, it takes about an hour before that changes into something else, but still the "reach" counter keeps staying at 0.
the "as" command gives following:
ind assID status conf reach auth condition last_event cnt
1 40263 9614 yes yes none sys.peer reachable 1 2 40264 8000 yes yes none reject 3 40265 8000 yes yes none reject 4 40266 8000 yes yes none reject
This does not change even after 24h, it is always "reject".
Querying with "rv" always gets the response "peer_unfit" and "peer_stratum" which is natural since the stratum stays at 16 all the time.
Sounds like a network problem, yet I do not find the problem.
I have no rule whatsoever in the ASA restricting or allowing the port 123 for NTP. But theoretically I should not need it - for UDP the firewall SHOULD know that the reply packet is related / established so it should let it through, or am I wrong here?
Or is the problem related to some authentication config - does the ntp key line in the confi g have anything to do with it?
EDIT: FIREWALL ASA 5505 CONFIG (shortened):
ASA Version 8.2(5) ! names ! interface Ethernet0/0 switchport access vlan 2 ! interface Ethernet0/1 ! interface Ethernet0/2 ! interface Ethernet0/3 ! interface Ethernet0/4 ! interface Ethernet0/5 switchport access vlan 3 ! interface Ethernet0/6 switchport access vlan 3 ! interface Ethernet0/7 switchport access vlan 3 ! interface Vlan1 nameif inside security-level 100 ip address 10.111.11.251 255.255.255.0 ! interface Vlan2 nameif outside security-level 0 ip address 192.168.1.2 255.255.255.252 ! interface Vlan3 no forward interface Vlan1 nameif dmz security-level 50 ip address 192.168.240.254 255.255.255.0 ! ! ftp mode passive clock timezone CEST 1 clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 2:00 object-group network XenServer network-object host 192.168.240.240 network-object host 192.168.240.241 network-object host 192.168.240.242 access-list MAILSERVER extended permit tcp any any eq www access-list MAILSERVER extended permit tcp any any eq https access-list MAILSERVER extended permit tcp any any eq smtp access-list MAILSERVER extended permit tcp any any eq ftp access-list MAILSERVER extended permit tcp any any eq ftp-data access-list MAILSERVER extended permit icmp any any echo-reply access-list MAILSERVER extended deny ip any any log access-list NEPLAN extended permit tcp any host 192.168.240.231 eq 10000 access-list NEPLAN extended permit tcp any host 192.168.240.231 eq https access-list NEPLAN extended permit tcp any host 192.168.240.253 eq 10000 access-list NEPLAN extended permit tcp any host 192.168.240.253 eq https access-list NEPLAN extended permit tcp any object-group XenServer eq https access-list NEPLAN extended permit tcp any object-group XenServer eq ssh access-list NEPLAN extended permit tcp any host 192.168.240.231 eq www access-list NEPLAN extended permit tcp any host 192.168.240.238 eq www access-list INTERNET extended permit ip 192.168.240.0 255.255.255.128 any access-list INTERNET extended permit ip host 192.168.240.136 any access-list INTERNET extended permit ip host 192.168.240.230 any access-list INTERNET extended permit ip host 192.168.240.220 any access-list INTERNET extended permit ip host 192.168.240.221 any access-list INTERNET extended permit ip host 192.168.240.222 any access-list INTERNET extended permit ip host 192.168.240.210 any access-list INTERNET extended permit ip host 192.168.240.211 any access-list INTERNET extended permit icmp any any echo-reply access-list INTERNET extended permit ip object-group XenServer any access-list INTERNET extended deny ip any any log mtu inside 1500 mtu outside 1500 mtu dmz 1500 icmp unreachable rate-limit 1 burst-size 1 arp timeout 14400 global (outside) 91 interface global (dmz) 92 interface nat (inside) 92 10.111.11.0 255.255.255.0 nat (dmz) 91 192.168.240.0 255.255.255.0 static (dmz,outside) tcp interface https 192.168.240.136 https netmask 255.255.255.255 static (dmz,outside) tcp interface smtp 192.168.240.136 smtp netmask 255.255.255.255 static (dmz,outside) tcp interface ftp 192.168.240.136 ftp netmask 255.255.255.255 static (dmz,outside) tcp interface ftp-data 192.168.240.136 ftp-data netmask 255.255.255.255 static (dmz,outside) tcp interface www 192.168.240.136 www netmask 255.255.255.255 access-group NEPLAN in interface inside access-group MAILSERVER in interface outside access-group INTERNET in interface dmz route outside 0.0.0.0 0.0.0.0 192.168.1.1 1 ntp server 89.109.251.21 ntp server 176.9.47.150 ntp server 63.15.238.180 webvpn ! class-map inspection_default match default-inspection-traffic ! ! policy-map type inspect dns preset_dns_map parameters message-length maximum client auto message-length maximum 512 policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect ip-options inspect netbios inspect rsh inspect rtsp inspect skinny inspect esmtp inspect sqlnet inspect sunrpc inspect tftp inspect sip inspect xdmcp ! service-policy global_policy global prompt hostname context no call-home reporting anonymous call-home profile CiscoTAC-1 no active destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService destination address email [email protected] destination transport-method http subscribe-to-alert-group diagnostic subscribe-to-alert-group environment subscribe-to-alert-group inventory periodic monthly subscribe-to-alert-group configuration periodic monthly subscribe-to-alert-group telemetry periodic daily Cryptochecksum:590d5cd7306d6a21eb875098d3b33661 : end NEP-ASA-SL20-1#
The servers which have problems with NTP are 192.168.240.240 and 192.168.240.241 (network object group XenServers - this is a XenServer DomU. Tried already with another standalone server - same problem so it doesn't seem related to Xen).
You don't have the ASA configured to allow outgoing NTP traffic, so it doesn't. "Related/established" traffic refers to in-progress traffic, such as incoming replies from NTP servers, not newly initiated traffic, so it doesn't apply here.
To resolve the issue, add rules for the appropriate groups to allow outgoing NTP traffic. For example:
The solution for this is to add a static NAT entry for UDP packets with destination port 123 (plus open that inbound port specifically):
Yes, I know, this SHOULD not be necessary. Opening the inbound port 123 specifically does not handle it - it does require the static NAT entry. This also shows that the UDP packets sent by my CentOS server have both destination and source port set to 123 for NTP.
Can anyone shed light on why the firewall refuses to classify this traffic as related traffic? Is this because the source port is an "privileged" port, i.e. < 1023? I cannot find any documentation or reference anywhere on this.