[CentOS] NTP server problem behind firewall

Tue Sep 4 06:31:48 UTC 2012

On Mon, Sep 3, 2012 at 4:32 PM, Giles Coochey <giles at coochey.net> wrote:
> On 03/09/2012 15:18, Artifex Maximus wrote:
>>
>> On Mon, Sep 3, 2012 at 11:15 AM, Leonard den Ottolander
>> <leonard at den.ottolander.nl> wrote:
>>>
>>> On Sun, 2012-09-02 at 07:46 +0000, Artifex Maximus wrote:
>>>>
>>>> Any idea what is wrong?
>>>
>>> The iptables rules you specify only allow clients from your local
>>> network access to your "proxy" ntp server. However, you do not specify
>>> any rules for eth1 to allow that ntp server to synchronise with the
>>> remote servers it is using. So unless you are using a local time source
>>> that might be your problem.
>>>
>>> Btw, when specifying rules for the external ntp servers you might want
>>> to specify IPs as well to restrict access.
>>
>> Thanks. You are right ntp proxy is absolutely what I want. Mine
>> description was not clean probably. So this is the setup:
>>
>> GPSNTP(10.0.1.99/24) - eth1 myserver eth0 - clients(10.0.0.0/24)
>>
>> Because GPSNTP is on a physically separated network I need this proxy
>> for my clients. My server is able to synchronize with GPSNTP so rules
>> are fine for that (because my output chain is ACCEPT per default). My
>> clients whom are cannot synchronize with my server even if I allow NTP
>> port which I do not understand.
>>
>>
> So at this stage, doing a "tcpdump -i eth0 -s 0 -w capture.cap" and getting
> one of your clients to try to sync time with your server and then repeating
> this with the firewall turned off (when it purportedly works) ought to give
> you enough information to be able to view the packet capture and see what is
> going wrong.

Thanks for the answer. I did tcpdump with turned on firewall but not
exactly what you suggest. The command was:

tcpdump -i eth0 -c 50 -nn -N -s 0 -vv port 123

and the result is:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
65535 bytes
16:39:13.653674 IP (tos 0x0, ttl 128, id 23478, offset 0, flags
[none], proto UDP (17), length 76)
    10.0.1.178.123 > 10.0.0.99.123: [udp sum ok] NTPv3, length 48
        symmetric active, Leap indicator: clock unsynchronized (192),
Stratum 0 (unspecified), poll 4s, precision -6
        Root Delay: 0.000610, Root dispersion: 9.049407, Reference-ID: (unspec)
          Reference Timestamp:  3555678802.057624999 (2012/09/03 16:33:22)
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3555679152.630750000 (2012/09/03 16:39:12)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3555679152.630750000
(2012/09/03 16:39:12)

16:39:43.145984 IP (tos 0x0, ttl 128, id 24616, offset 0, flags
[none], proto UDP (17), length 76)
    10.0.0.150.123 > 10.0.0.99.123: [udp sum ok] NTPv3, length 48
        symmetric active, Leap indicator: clock unsynchronized (192),
Stratum 0 (unspecified), poll 4s, precision -6
        Root Delay: 0.000610, Root dispersion: 9.049407, Reference-ID: (unspec)
          Reference Timestamp:  3555678802.057624999 (2012/09/03 16:33:22)
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3555679182.130750000 (2012/09/03 16:39:42)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3555679182.130750000
(2012/09/03 16:39:42)
16:39:43.145991 IP (tos 0x0, ttl 128, id 24617, offset 0, flags
[none], proto UDP (17), length 76)
    10.0.1.178.123 > 10.0.0.99.123: [udp sum ok] NTPv3, length 48
        symmetric active, Leap indicator: clock unsynchronized (192),
Stratum 0 (unspecified), poll 4s, precision -6
        Root Delay: 0.000610, Root dispersion: 9.049407, Reference-ID: (unspec)
          Reference Timestamp:  3555678802.057624999 (2012/09/03 16:33:22)
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3555679182.130750000 (2012/09/03 16:39:42)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3555679182.130750000
(2012/09/03 16:39:42)
16:39:43.146020 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 76)
    10.0.0.99.123 > 10.0.0.150.123: [bad udp cksum 9133!] NTPv3, length 48
        symmetric active, Leap indicator:  (0), Stratum 2 (secondary
reference), poll 4s, precision -23
        Root Delay: 0.000625, Root dispersion: 0.043029, Reference-ID: 10.0.1.99
          Reference Timestamp:  3555677676.775420963 (2012/09/03 16:14:36)
          Originator Timestamp: 3555679182.130750000 (2012/09/03 16:39:42)
          Receive Timestamp:    3555679183.145983964 (2012/09/03 16:39:43)
          Transmit Timestamp:   3555679183.146011888 (2012/09/03 16:39:43)
            Originator - Receive Timestamp:  +1.015233964
            Originator - Transmit Timestamp: +1.015261886

The first time (16:39:13.653674) client cannot sync to the server but
second time (16:39:43.145984) that was successful even if there is a
'bad udp cksum'. BTW, is it normal? Tcpdump says there was traffic and
sync happened later so rule is OK I think.

When tried later sync needs three tries for success. Other time needs
only one. Might depend on Moon phase. It looks like I have some
network equipment related problem as well. Therefore I have to talk
with some Cisco expert.

At the moment I have problem with rsyslogd because there is no log of
denied packets but that is another story. :-)

Thanks for all of your help!

Bye,
a