Hello!
I would like to setup an NTP server for my Windows network using CentOS 6.3 with firewall turned on. As I learned the NTP protocol uses port 123 UDP. I have two NIC cards. One for internal network and one for access internet. Both cards in private address range. The problem is when I am using firewall described below the client cannot access the server. No idea why. Without firewall everything works flawless. So the problem is not in the NTP configuration. No idea why but with disabled firewall the first query gives error but all other query is work. I am using arpwatch to see what is happen on network (new machines and so). Not know is that related to the problem or not.
First I had used the system-config-firewall generated firewall (standard firewall with port 123:udp added). No success, client cannot connect.
Next I made a script for myself and saved with 'service iptables save' command. The configuration is:
eth0 10.0.0.99/24 eth1 10.0.1.10/24
The script for making firewall rules: iptables -P INPUT ACCEPT iptables -F iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p udp --dport 123 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p tcp --dport 123 -j ACCEPT iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 iptables -A INPUT -j DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
Windows client time server is set to 10.0.0.99. Just for sure I enabled 123 TCP as well even I think that was unnecessary. The rule which related to NTP (123 UDP) increments its packet and byte count with 'iptables -L -n -v' so some connection was made. But no success on sync.
Any idea what is wrong?
Bye, a
On Sun, 2012-09-02 at 07:46 +0000, Artifex Maximus wrote:
Hello!
I would like to setup an NTP server for my Windows network using CentOS 6.3 with firewall turned on. As I learned the NTP protocol uses port 123 UDP. I have two NIC cards. One for internal network and one for access internet. Both cards in private address range. The problem is when I am using firewall described below the client cannot access the server. No idea why. Without firewall everything works flawless. So the problem is not in the NTP configuration. No idea why but with disabled firewall the first query gives error but all other query is work. I am using arpwatch to see what is happen on network (new machines and so). Not know is that related to the problem or not.
First I had used the system-config-firewall generated firewall (standard firewall with port 123:udp added). No success, client cannot connect.
Next I made a script for myself and saved with 'service iptables save' command. The configuration is:
eth0 10.0.0.99/24 eth1 10.0.1.10/24
The script for making firewall rules: iptables -P INPUT ACCEPT iptables -F iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p udp --dport 123 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p tcp --dport 123 -j ACCEPT iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 iptables -A INPUT -j DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
I might be wrong but I think you need to add the IP Address of the NTP server
you can also use tcpdump to capture the traffic between the clients and the ntp server to see what is being blocked.
# iptables -A OUTPUT -o eth0 -p udp -s <client IPs> --sport 123 -d <NTP Server IP> --dport 123 -m state --state NEW -j ACCEPT.
Windows client time server is set to 10.0.0.99. Just for sure I enabled 123 TCP as well even I think that was unnecessary. The rule which related to NTP (123 UDP) increments its packet and byte count with 'iptables -L -n -v' so some connection was made. But no success on sync.
Any idea what is wrong?
Bye, a _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, Sep 2, 2012 at 8:37 AM, Earl Ramirez earlaramirez@gmail.com wrote:
On Sun, 2012-09-02 at 07:46 +0000, Artifex Maximus wrote:
Hello!
I would like to setup an NTP server for my Windows network using CentOS 6.3 with firewall turned on. As I learned the NTP protocol uses port 123 UDP. I have two NIC cards. One for internal network and one for access internet. Both cards in private address range. The problem is when I am using firewall described below the client cannot access the server. No idea why. Without firewall everything works flawless. So the problem is not in the NTP configuration. No idea why but with disabled firewall the first query gives error but all other query is work. I am using arpwatch to see what is happen on network (new machines and so). Not know is that related to the problem or not.
First I had used the system-config-firewall generated firewall (standard firewall with port 123:udp added). No success, client cannot connect.
Next I made a script for myself and saved with 'service iptables save' command. The configuration is:
eth0 10.0.0.99/24 eth1 10.0.1.10/24
The script for making firewall rules: iptables -P INPUT ACCEPT iptables -F iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p udp --dport 123 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p tcp --dport 123 -j ACCEPT iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 iptables -A INPUT -j DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
I might be wrong but I think you need to add the IP Address of the NTP server
Why? I am using a more general form of INPUT rule.
you can also use tcpdump to capture the traffic between the clients and the ntp server to see what is being blocked.
Thanks for your answer. Good idea and I'll do it.
# iptables -A OUTPUT -o eth0 -p udp -s <client IPs> --sport 123 -d <NTP Server IP> --dport 123 -m state --state NEW -j ACCEPT.
I am using
iptables -P OUTPUT ACCEPT
which allows all OUTPUT traffic on all interface as default rule. So I do not think that I need any more specific rule.
Bye, a
On 2.9.2012 09:46, Artifex Maximus wrote:
Hello!
I would like to setup an NTP server for my Windows network using CentOS 6.3 with firewall turned on. As I learned the NTP protocol uses port 123 UDP. I have two NIC cards. One for internal network and one for access internet. Both cards in private address range. The problem is when I am using firewall described below the client cannot access the server. No idea why. Without firewall everything works flawless. So the problem is not in the NTP configuration. No idea why but with disabled firewall the first query gives error but all other query is work. I am using arpwatch to see what is happen on network (new machines and so). Not know is that related to the problem or not.
First I had used the system-config-firewall generated firewall (standard firewall with port 123:udp added). No success, client cannot connect.
Next I made a script for myself and saved with 'service iptables save' command. The configuration is:
eth0 10.0.0.99/24 eth1 10.0.1.10/24
The script for making firewall rules: iptables -P INPUT ACCEPT iptables -F iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p udp --dport 123 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p tcp --dport 123 -j ACCEPT iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 iptables -A INPUT -j DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
you must ACCEPT ntp in the FORWARD chain. http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-6.html
On Sun, Sep 2, 2012 at 2:33 PM, Markus Falb markus.falb@fasel.at wrote:
On 2.9.2012 09:46, Artifex Maximus wrote:
Hello!
I would like to setup an NTP server for my Windows network using CentOS 6.3 with firewall turned on. As I learned the NTP protocol uses port 123 UDP. I have two NIC cards. One for internal network and one for access internet. Both cards in private address range. The problem is when I am using firewall described below the client cannot access the server. No idea why. Without firewall everything works flawless. So the problem is not in the NTP configuration. No idea why but with disabled firewall the first query gives error but all other query is work. I am using arpwatch to see what is happen on network (new machines and so). Not know is that related to the problem or not.
First I had used the system-config-firewall generated firewall (standard firewall with port 123:udp added). No success, client cannot connect.
Next I made a script for myself and saved with 'service iptables save' command. The configuration is:
eth0 10.0.0.99/24 eth1 10.0.1.10/24
The script for making firewall rules: iptables -P INPUT ACCEPT iptables -F iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p udp --dport 123 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p tcp --dport 123 -j ACCEPT iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 iptables -A INPUT -j DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
you must ACCEPT ntp in the FORWARD chain. http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-6.html
Thanks. Why?
"If it's destined for this box, the packet passes downwards in the diagram, to the INPUT chain. If it passes this, any processes waiting for that packet will receive it."
The packet destination is my server because NTP server is there so it passes to input box where 123 UDP is enabled. If I read the how-to correctly.
Bye, a
On 2.9.2012 18:22, Artifex Maximus wrote:
On Sun, Sep 2, 2012 at 2:33 PM, Markus Falb markus.falb-fSWCc0FX9k8@public.gmane.org wrote:
On 2.9.2012 09:46, Artifex Maximus wrote:
Hello!
I would like to setup an NTP server for my Windows network using CentOS 6.3 with firewall turned on.
...
The script for making firewall rules: iptables -P INPUT ACCEPT iptables -F iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p udp --dport 123 -j ACCEPT iptables -A INPUT -i eth0 -s 10.0.0.0/24 -p tcp --dport 123 -j ACCEPT iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 iptables -A INPUT -j DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
you must ACCEPT ntp in the FORWARD chain. http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-6.html
Thanks. Why?
...
The packet destination is my server because NTP server is there so it passes to input box where 123 UDP is enabled. If I read the how-to correctly.
I thought you wanted to forward to another host. I think I was confused because you mentioned the 2 NIC cards. Sorry.
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.
Regards, Leonard.
Le lun. 03 sept. 2012 13:15:41 CEST, Leonard den Ottolander a écrit:
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.
I don't think this is the problem : the firewall accept everything in the output chain, and established/related in input : my ntp server works fine with the same rules (123/tcp is indeed useless).
For me, the problem is not ntp+iptables, or it should appears in /var/log/messages, thanks to the -j LOG. There can be something wrong in ntp.conf (but this is probably not the case since it works without firewall), in the firewall (for example, if it blocks DNS requests), or in the network configuration.
Regards,
On 03/09/2012 13:00, Philippe Naudin wrote:
Le lun. 03 sept. 2012 13:15:41 CEST, Leonard den Ottolander a écrit:
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.
I don't think this is the problem : the firewall accept everything in the output chain, and established/related in input : my ntp server works fine with the same rules (123/tcp is indeed useless).
For me, the problem is not ntp+iptables, or it should appears in /var/log/messages, thanks to the -j LOG. There can be something wrong in ntp.conf (but this is probably not the case since it works without firewall), in the firewall (for example, if it blocks DNS requests), or in the network configuration.
Regards,
Does 'ntpq -p' show your server actually syncing with ntp hosts?
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.
Bye, a
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.
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
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.
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
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.
-
Artifex Maximus -
Earl Ramirez -
Giles Coochey -
Leonard den Ottolander -
Markus Falb -
Philippe Naudin