On Mon, Sep 3, 2012 at 4:32 PM, Giles Coochey <giles@xxxxxxxxxxx> wrote:
> On 03/09/2012 15:18, Artifex Maximus wrote:
>>
>> On Mon, Sep 3, 2012 at 11:15 AM, Leonard den Ottolander
>> <leonard@xxxxxxxxxxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
