3

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

2
  • Can you show your firewall's config?
    – ewwhite
    Jun 3, 2013 at 13:36
  • See above in EDIT
    – nepdev
    Jun 3, 2013 at 14:42

2 Answers 2

1

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:

access-list NEPLAN extended permit udp any any eq 123
1
  • True enough - but this should be already taken care of - in fact I allow all IP traffic out for these servers (they are as noted above in the XenServer group): access-list INTERNET extended permit ip object-group XenServer any - I do get out on the internet and any other ports
    – nepdev
    Jun 3, 2013 at 21:06
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .