FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 09-03-2012, 04:56 PM
Leonard den Ottolander
 
Default NTP server problem behind firewall

On Mon, 2012-09-03 at 14:18 +0000, Artifex Maximus wrote:
> My server is able to synchronize with GPSNTP so rules
> are fine for that (because my output chain is ACCEPT per default).

And related traffic is allowed too, yes, I overlooked that.

Are you sure your windows clients have addresses in the 10.0.0.x range
and not 10.x.y.z and the netmask on eth0 is 24 not 8 (which is the
default)?

Regards,
Leonard.

--
mount -t life -o ro /dev/dna /genetic/research


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-04-2012, 06:31 AM
Artifex Maximus
 
Default NTP server problem behind firewall

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-04-2012, 08:36 AM
Giles Coochey
 
Default NTP server problem behind firewall

On 04/09/2012 07:31, Artifex Maximus wrote:


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!


Without seeing the full timeline of events, you should bear in mind that
there will be a gap between the time that an NTP server is started
before other clocks are allowed to sync to it. This makes sense as you
wouldn't want to sync time to a source that itself isn't reliable. Once
the NTP server fulfils some criteria and believes it's clock to be
reliable, it will allow other systems to sync to it.


--
Regards,

Giles Coochey, CCNA, CCNAS
NetSecSpec Ltd
+44 (0) 7983 877438
http://www.coochey.net
http://www.netsecspec.co.uk
giles@coochey.net


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-04-2012, 10:18 AM
Artifex Maximus
 
Default NTP server problem behind firewall

On Tue, Sep 4, 2012 at 10:36 AM, Giles Coochey <giles@coochey.net> wrote:
> On 04/09/2012 07:31, Artifex Maximus wrote:
>>
>>
>> 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!
>>
>>
> Without seeing the full timeline of events, you should bear in mind that
> there will be a gap between the time that an NTP server is started before
> other clocks are allowed to sync to it. This makes sense as you wouldn't
> want to sync time to a source that itself isn't reliable. Once the NTP
> server fulfils some criteria and believes it's clock to be reliable, it will
> allow other systems to sync to it.

I know and respect that. I tried only after my NTP was synchronized
and declared as reliable. Otherwise I get some stratum error on client
which is normal I think.

Bye,
a
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 07:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org