NTP and the need to create packet filter rules

So my question is: what is the meaning of "Allowed Networks" if I have to manually create packetfilter rules?

I tried with a linux client (a network camera) and it syncronize successfully! So the problem is related to windows client! Mmm very strange don't you think? 

NTP Service definition is this one: 
Type: TPC/UDP
Source Port: 1:65535
Destination Port: 123

The only reason is that the auto-packet filter rule created when an Allowed Network is added is not the same rule manually created...

Hi

Had a look at the filter rules it generates if the network is in the allowed networks:

It's in the AUTO_INPUT chain:
CONFIRMED  udp  --  *      *       ***.xx.xx.xx/xx        0.0.0.0/0           udp spts:123:65535 dpt:123 CONFIRMED

First thing asking me was, why is the destination 0.0.0.0/0 ? Shouldn't it be the firewall address of the source network?

Source port is 123-65535, which should be fine, because NTP should use 123 as source port anyway. OK, don't know what Windows is really doing... (Who knows that at all :-D )

First, really make sure the correct network was added to allowed networks. Maybe try to add "Any", just to see if it works then.

Second, disable the Windows firewall on the NTP client if it is enabled. Maybe it is blocking something because it's UDP (even if it works with the manual rule)

You may can use Wireshark on the Windows client and look what it is really doing.

Hi
Had a look at the filter rules it generates if the network is in the allowed networks:
It's in the AUTO_INPUT chain:

Hi Whity, 
what is auto_input? is it a file? I am not familiar with linux, can you please suggest me where can I find it?

First thing asking me was, why is the destination 0.0.0.0/0 ? Shouldn't it be the firewall address of the source network?

The destination is Internal (Address), so the firewall address of internal interface card, not 0.0.0.0/0.

First, really make sure the correct network was added to allowed networks. Maybe try to add "Any", just to see if it works then.

Second, disable the Windows firewall on the NTP client if it is enabled. Maybe it is blocking something because it's UDP (even if it works with the manual rule)

In this moment we have an important meeting, I prefer not to try your suggestion now, I'll do it later [;)]
 

You may can use Wireshark on the Windows client and look what it is really doing.

This is a good idea!

what is auto_input? is it a file? I am not familiar with linux, can you please suggest me where can I find it?

It's just a filter chain from IPtables, you don't have to care about.

The destination is Internal (Address), so the firewall address of internal interface card, not 0.0.0.0/0.

Was more a question to the Astaro guys. But think i found out myself in the meantime. Because its an input chain, it only allows connection to the interfaces of the astaro. So, that's fine.

From Internal (Network) to Internal (Address) NTP service.
From DMZ (Network) to DMZ (Address) NTP service.

Whity didn't mention it, but these rules cannot have any effect on anything.

Cheers - Bob

Whity didn't mention it, but these rules cannot have any effect on anything.

Cheers - Bob

You are right, I discovered that the issue is random. Only for a coincidence the packetfilter rule seemed to take effect. 

I have tried to inspect the packets with WireShark. When client can receive the correct date/time, the Astaro response is this:

Network Time Protocol
    Flags: 0x19
        00.. .... = Leap Indicator: no warning (0)
        ..01 1... = Version number: NTP Version 3 (3)
        .... .001 = Mode: symmetric active (1)
    Peer Clock Stratum: secondary reference (11)
    Peer Polling Interval: 4 (16 sec)
    Peer Clock Precision: 0,000004 sec
    Root Delay:    0,0000 sec
    Root Dispersion:    0,0127 sec
    Reference Clock ID: 127.127.1.0
    Reference Clock Update Time: Jul 12, 2010 13:50:28,2258 UTC
    Originate Time Stamp: Jul 12, 2010 13:51:23,7070 UTC
    Receive Time Stamp: Jul 12, 2010 13:51:23,4025 UTC
    Transmit Time Stamp: Jul 12, 2010 13:51:23,4026 UTC


When client cannot receive date/time, the Astaro response is this:

Network Time Protocol
    Flags: 0xd9
        11.. .... = Leap Indicator: alarm condition (clock not synchronized) (3)
        ..01 1... = Version number: NTP Version 3 (3)
        .... .001 = Mode: symmetric active (1)
    Peer Clock Stratum: unspecified or unavailable (0)
    Peer Polling Interval: 5 (32 sec)
    Peer Clock Precision: 0,000004 sec
    Root Delay:    0,0000 sec
    Root Dispersion:    0,0015 sec
    Reference Clock ID: (Initialization)
    Reference Clock Update Time: NULL
    Originate Time Stamp: Jul 12, 2010 13:37:08,2392 UTC
    Receive Time Stamp: Jul 12, 2010 13:37:07,9361 UTC
    Transmit Time Stamp: Jul 12, 2010 13:37:07,9361 UTC


So it seems an issue in NTP server built-in astaro... isn't it?

So it seems an issue in NTP server built-in astaro... isn't it?

[:@][:@][:@] Damn! WinWASTE

Meinberg Funkuhren - FAQ - Why does my Windows Time Service (w32time) not synchronize with my NTP Server?

It's a problem with xp/2003 ntp client! [:@]

Thanks! I've been having trouble with my NTP XP boxes ever since Astaro put in an NTP server (v7).

Barry

Thanks! I've been having trouble with my NTP XP boxes ever since Astaro put in an NTP server (v7).
Barry

[;)] when I went in Redmon I had to drop a bomb!! [:P]

Did anyone have any luck with this config on WinXP SP3?

I'm getting errors:
C:\>w32tm /resync
Sending resync command to local computer...
The computer did not resync because no time data was available.


I used
w32tm /config /manualpeerlist:"192.168.11.1,0x8" /syncfromflags:MANUAL /update


Thanks,
Barry