On Mon, Sep 3, 2012 at 4:32 PM, Giles Coochey giles@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@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