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 callhome@cisco.com
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).
Answer
The solution for this is to add a static NAT entry for UDP packets with destination port 123 (plus open that inbound port specifically):
static (dmz,outside) udp interface ntp 192.168.240.240 ntp netmask 255.255.255.255
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.
No comments:
Post a Comment