[ntp:questions] Firewall requirements for NTP as both client and server

David Taylor david-taylor at blueyonder.co.uk.invalid
Sun Dec 28 18:14:06 UTC 2014


On 28/12/2014 17:07, Mike Cook wrote:
>
>> Le 28 déc. 2014 à 17:11, David Taylor <david-taylor at blueyonder.co.uk.invalid> a écrit :
>>
>> I'm trying to understand the firewall requirements for NTP.  Using the FreeBSD ipfw I have the following, which appears to allow NTPns to operate as a client, i.e. it can get times from other servers on my LAN, and even from the WAN.
>>
>>   add 100 allow udp from any to any 123
>>   add 200 allow udp from any 123 to any
>>
>   Check " with ipfw -S show "that you are getting the result you want:
>
>> However, other servers on the same LAN appear not to be able to see this NTPns server, always being in an INIT state.  I wonder whether this might be a firewall issue, or whether the settings above should suffice both for NTPns as a client, and as a server.  My reading is that they should, but I'm very unfamiliar with ipfw (and that's what I have to use).
>>
>
> I use the following for my 4801 on 192.168.1.3 (show result), allowing all NTP requests IN
> 00960     5560    1149140 set 8 allow udp from any to 192.168.1.3 dst-port 123 via sis0 keep-state
> and letting any server initiated request out. I don’t restrict outgoing packets as I am the only user.
> 05100  9721814 1149904224 set 0 allow ip from 192.168.1.3 to any keep-state
>
> when I get odd things like this happening I select logging and see what is / is not getting through.
> ex.
> 00705   717773  274869433 set 2 allow log ip from not 192.168.0.0/16 to 192.168.1.3 dst-port 80 via sis0 keep-state
> to log all incoming http from the internet.
>
> It could be that your other servers have firewalls restricting some address traffic .
>
> you can use tcpdump to see what is on your LAN
>
> $ sudo tcpdump -p udp port 123
> Password:
> Hold it up to the light --- not a brain in sight!
> Password:
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on sis0, link-type EN10MB (Ethernet), capture size 96 bytes
> 18:06:01.575375 IP gluon.stratum1.d2g.com.ntp > ntp-p1.obspm.fr.ntp: NTPv4, Client, length 48
> 18:06:02.575056 IP gluon.stratum1.d2g.com.ntp > ns1.nexellent.net.ntp: NTPv4, Client, length 48
> 18:06:02.597744 IP ns1.nexellent.net.ntp > gluon.stratum1.d2g.com.ntp: NTPv4, Server, length 48
> 18:06:03.575860 IP gluon.stratum1.d2g.com.ntp > ch-ntp01.swiss-networks.net.ntp: NTPv4, Client, length 48
> 18:06:03.601883 IP ch-ntp01.swiss-networks.net.ntp > gluon.stratum1.d2g.com.ntp: NTPv4, Server, length 48
> 18:06:05.575561 IP gluon.stratum1.d2g.com.ntp > laurelineA.stratum1.d2g.com.ntp: NTPv4, Client, length 48
> 18:06:05.575815 IP laurelineA.stratum1.d2g.com.ntp > gluon.stratum1.d2g.com.ntp: NTPv4, Server, length 48
> 18:06:14.575661 IP gluon.stratum1.d2g.com.ntp > muon.stratum1.d2g.com.ntp: NTPv4, Client, length 48
> 18:06:14.576758 IP muon.stratum1.d2g.com.ntp > gluon.stratum1.d2g.com.ntp: NTPv4, Server, length 48
> 18:06:15.575563 IP gluon.stratum1.d2g.com.ntp > raspb1.home.ntp: NTPv4, Client, length 48
> 18:06:15.576416 IP raspb1.home.ntp > gluon.stratum1.d2g.com.ntp: NTPv4, Server, length 48
>
> have fun
========================================

Not sure that "fun" is quite the word to describe it!

But that's a big help, Mike.  At least I think it is.  I would not have 
known the best options for tcpdump, although I have heard of the 
command.  My raw tcpdump is, and sorry about the wrap!

tcpdump -p udp port 123

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on sis0, link-type EN10MB (Ethernet), capture size 68 bytes
17:45:15.792240 IP 192.168.0.1.ntp > net4501.ntp: NTPv4, Client, length 48
17:45:48.808107 IP 192.168.0.1.ntp > net4501.ntp: NTPv4, Client, length 48
17:45:53.555475 IP net4501.ntp > 192.168.0.3.ntp: NTPv4, Client, length 48
17:45:53.555875 IP 192.168.0.3.ntp > net4501.ntp: NTPv4, Server, length 48
17:45:53.619489 IP net4501.ntp > 192.168.0.8.ntp: NTPv4, Client, length 48
17:45:53.620498 IP 192.168.0.8.ntp > net4501.ntp: NTPv4, Server, length 48
17:45:53.643496 IP net4501.ntp > 192.168.0.1.ntp: NTPv4, Client, length 48
17:45:53.643889 IP 192.168.0.1.ntp > net4501.ntp: NTPv4, Server, length 48
17:46:20.823583 IP 192.168.0.1.ntp > net4501.ntp: NTPv4, Client, length 48
17:46:52.838966 IP 192.168.0.1.ntp > net4501.ntp: NTPv4, Client, length 48
17:46:57.556443 IP net4501.ntp > 192.168.0.3.ntp: NTPv4, Client, length 48
17:46:57.556740 IP 192.168.0.3.ntp > net4501.ntp: NTPv4, Server, length 48
17:46:57.621216 IP net4501.ntp > 192.168.0.8.ntp: NTPv4, Client, length 48
17:46:57.622110 IP 192.168.0.8.ntp > net4501.ntp: NTPv4, Server, length 48
17:46:57.643393 IP net4501.ntp > 192.168.0.1.ntp: NTPv4, Client, length 48
17:46:57.643951 IP 192.168.0.1.ntp > net4501.ntp: NTPv4, Server, length 48
^C
16 packets captured
542 packets received by filter
0 packets dropped by kernel

which I think I can separate into two groups.  The first is where the 
net4501 as a client is making requests to its servers, and getting 
responses back:

17:45:53.555475 IP net4501.ntp > 192.168.0.3.ntp: NTPv4, Client, length 48
17:45:53.555875 IP 192.168.0.3.ntp > net4501.ntp: NTPv4, Server, length 48
17:45:53.619489 IP net4501.ntp > 192.168.0.8.ntp: NTPv4, Client, length 48
17:45:53.620498 IP 192.168.0.8.ntp > net4501.ntp: NTPv4, Server, length 48
17:45:53.643496 IP net4501.ntp > 192.168.0.1.ntp: NTPv4, Client, length 48
17:45:53.643889 IP 192.168.0.1.ntp > net4501.ntp: NTPv4, Server, length 48

The others are where a PC (192.168.0.1) is asking the net4501 for the 
time, but not getting a response:

17:46:20.823583 IP 192.168.0.1.ntp > net4501.ntp: NTPv4, Client, length 48
17:46:52.838966 IP 192.168.0.1.ntp > net4501.ntp: NTPv4, Client, length 48

They are 32 seconds approximately apart which is what I would expect. 
SO does that mean that the firewall has blocked them, or that the NTPns 
server never responded?  There is no firewall block on 192.168.0.1 
making requests and getting responses from servers on or off the LAN.

I'll investigate NTPns further....

-- 
Cheers,
David
Web: http://www.satsignal.eu



More information about the questions mailing list