Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 23 replies
  • Subscribers 2 subscribers
  • Views 110272 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NTP not working??

martindw
I'm having a problem getting NTP packets to pass through my firewall.  My NTP client (MRTech ClockAlign) has three options for protocol to use. . .SNMP, which works fine, and standard NTP via UDP or TCP, neither of which does.  The downer on this is that SNMP NTP requests have the least info of all types, I'm told.

I have defined NTP on my definitions as dest. port 37 UDP/TCP, send.port 1024:65535.  I have then created a rule in the packet filters that says "Any" NTP from "Any" allow.

Nevertheless, when I try to sync my clock using MRTech on TCP or UDP the packet filter shows the following:

11:51:30 192.168.0.33 2008  ->  192.5.41.40 37 TCP SYN  
11:51:30 192.168.0.33 2009  ->  192.5.41.40 37 TCP SYN  
11:51:34 192.168.0.33 2009  ->  192.5.41.40 37 TCP SYN  
11:51:34 192.168.0.33 2010  ->  192.5.41.40 37 TCP SYN  

and with UDP:

11:54:02 192.168.0.33 2074  ->  192.5.41.40 37 UDP  
11:54:06 192.168.0.33 2076  ->  192.5.41.40 37 UDP  
11:54:10 192.168.0.33 2079  ->  192.5.41.40 37 UDP  
11:54:14 192.168.0.33 2081  ->  192.5.41.40 37 UDP  
11:54:18 192.168.0.33 2083  ->  192.5.41.40 37 UDP 

Switch it to SNMP and it's fat & happy.

Any clues?

Thanks

Dan  


This thread was automatically locked due to age.
  • 0 in reply to Marcel_01
    Just for those who might be wondering, I sent the file to Marcel as requested the same day. . .no response yet.

    Dan  
  • 0 in reply to martindw
    Dan,

    even Astaro employees need some holiday  [;)]

    Let's focus on udp/123, therefore you have rule which apparently matches
    664 50464 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:123 dpt:123 

    So I assume that you have to check the client settings. The ntp server 192.5.41.40
    is up and running.

    In my opinion your rule should be more specific, so that only ineternal hosts can
    connect to ntp services.

    read you
    o|iver
      
  • 0 in reply to oliver.desch
    No objection for the holiday, Oliver.  I just wanted to keep the thread awake!

    My ntp client (MRTech ClockAlign 1.0) seems only to use port 37, not 123, as evidenced by the packet drop logs, which is why I had been concentrating on that port.

    The reason I had the rule as Any-Any is that the local NTP server I use on my WinNT4 machine (David Mills' NTP server v4) didn't work until I opened the port both ways.  I'm not saying this *should* be true  [:$]t was!

    Cheers,

    Dan  
  • 0 in reply to martindw
    *If* it is using udp/123, there are two types of NTP in my experience. One uses a high port (client end) ->port 123 on the server, the other uses 123->123 (ie: the connectino is from 123 to 123.

    From what you say, it would appear that your client is using 37 though, which, as pointed out above, is "time", not NTP. I have to admit not knowing the detailed differences. My NTP client Automachron --  http://oneguycoding.com  uses high port -> 123, and appears to work fine.

    Cheers,

    Karl

    PS: I have no interest in the NTP client, I just found it on the 'net, and it works, so I use it. 
  • 0 in reply to kd_03
    Lest the discussion get too far afield, however, the real issue is not NTP itself.  It is:  "Why on earth do I get packet drops showing in the log for a port which, according to WebAdmin, is open on my system?"  The fact that the port in question is NTP is only window-dressing; the *real* issue is the discrepancy between settings and function.

    Dan  
  • 0 in reply to martindw
    If computer "a" is trying to use service "x" on server "b", which is located on the internet, and there is a rule which should allow it, and you still get drops in the logs, I would ask "does the service work for computer 'a'?" I would guess not, in which case the rule may well be wrong in some way, and hence the drops. If, of course, the service does work, then there is something wierd going on.

    So.... can your network client sync ntp with the server? If not, the rule that should allow it, is wrong in some way......

    My NTP rule looks like :

    { net_private }   NTP-Async   Any   Allow

    Where NTP-Async is a built in service, defined as :

    NTP-Async   udp   1024:65535   123

    Cheers,

    Karl

     
  • 0 in reply to kd_03
    That gets back to the issue that is why I sent Marcel my config file.  As the thread above shows, there is no port 37 rule in IPChains, despite the fact that there's a rule that shows big as life in the WebAdmin menu of ASL.  This disconnect between the behind-the-scenes configuration and what shows on the menu is the whole reason I started this thread.

    As far as whether or not computer "a" (in this case, my workstation) has an NTP client that works, it does.  My final proof of that was temporarily enabling the deadliest rule of all--Any=>Any Allow-- and watching NTP work just fine.  Needless to say I don't leave that one on! 

    Dan  
  • 0 in reply to martindw
    Hmmm.... I'll be interested in any response from Astaro then.....

    Cheers,

    Karl 
  • 0
    Code:

    Hi,

    Not sure why this thread has lasted this long without a resolution, but unless you have a Packet Filter
    rule that is clobering your NTP rule, this is what I have in my configuration, and I have no issues.

    I access any NTP server from my LAN to the Internet using the following rules.


    Network / NAT/Masquerading
    	Intranet_to_Internet	 	Intranet -> All / All	 	MASQ__eth2	 	None


    Packet Filter / Rules
    	Intranet  	{ ntp }  	Any  	Allow


    ...and the details to define the objects:


    Definitions / Networks
    	Intranet  	192.168.2.0  	255.255.255.0


    Definitions / Services
    	NTP  		udp  	123  		123  	 	
    	NTP-Async 	udp 	1024:65535 	123


    Definitions / Service Groups
    	ntp
    		NTP
    		NTP-Async


    Using the above will certainly give you access to any NTP server from your Intranet to the Internet.

    Not sure if this is any help to you but I'm sure you can bend the "rules" to do what you need. :-)


    Regards
    kr8
      
  • 0
    Code:

    Incidentaly have you looked at the protocol definition?

    	See the RFC @ http://www.faqs.org/rfcs/rfc868.html

    You will see that you will need a service defined for TIME as below


    Definitions / Services
    	TIME-UDP	udp  	37  		37  	 	
    	TIME-TCP 	tcp 	37 		37


    Definitions / Service Groups
    	time
    		TIME-UDP
    		TIME-TCP

    So simply substitute the { ntp } entry for { time } and that is all you will need.

    If your not seeing rules appear in the iptables output then that is a matter for Astaro
    to investigate, but I see no reason why they should not appear.

    If they are not appearing, then I wonder if you have edited the config files by hand and
    have an unbalanced quote or similar. Or you have managed to introduce a non-printing character
    into your configuration due to a flaw in the input field validation of the backend module
    that handles this data.

    Hope you find a solution soon, you must be running out of "time" by now. :-)


    Regards
    kr8

    PS. I have no more time to help you I'm afraid. ;-)