I've been using the NTP-Server add-on on my Duo v.1. for many months now. It serves my Linux boxes beautifully.
Anyway, the problem(?):
I just modified the IPTables firewall on a Linux box using gufw, a GUI front end for ufw, which is to the best of my understanding a simplified command line front end for IPTables. After rebooting, everything works very fine, see below (the following was taken immediately after the machine booted):
[handy@jarmano ~]$ time Local time: Tue 2013-03-05 16:28:04 EST Universal time: Tue 2013-03-05 05:28:04 UTC RTC time: Tue 2013-03-05 05:28:04 Timezone: Australia/Sydney (EST, +1100) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: yes Last DST change: DST began at Sun 2012-10-07 01:59:59 EST Sun 2012-10-07 03:00:00 EST Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2013-04-07 02:59:59 EST Sun 2013-04-07 02:00:00 EST remote refid st t when poll reach delay offset jitter ============================================================================== 192.168.1.15 .XFAC. 16 u - 128 0 0.000 0.000 0.000 [handy@jarmano ~]$
But the time server stalls my machine for a 90 seconds, before moving on when booting?
Do I have to enable port 123? Do I need to do more than enabling port 123 in the firewall?
Thank you for your time, & please excuse me for invading it?
I made the firewall settings such that the ntp service is using the UDP protocol for both IN & OUT & now I get the following which is certainly an improvement, as at least now the delay, offset & jitter numbers look to be behaving as they should (instead of all being zero). But now I've got this:
NTP synchronized: no RTC in local TZ: no
when I use my time alias - the command follows:
alias time='timedatectl status && ntpq -c lpeer'
Here is the output from the above alias:
[handy@jarmano ~]$ time Local time: Fri 2013-03-08 19:28:45 EST Universal time: Fri 2013-03-08 08:28:45 UTC RTC time: Fri 2013-03-08 08:28:46 Timezone: Australia/Sydney (EST, +1100) NTP enabled: yes NTP synchronized: no RTC in local TZ: no DST active: yes Last DST change: DST began at Sun 2012-10-07 01:59:59 EST Sun 2012-10-07 03:00:00 EST Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2013-04-07 02:59:59 EST Sun 2013-04-07 02:00:00 EST remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.1.15 83.170.1.42 3 u 52 64 1 0.465 7.278 6.586
I ended up deleting the gufw rules & then using a small run once config file which setup just the basics for ufw & of course ntp. Then I added my incoming rules via gufw ('cause its so easy).
It works.
Now when I boot I wait for ~ 8 seconds instead of 90 seconds whilst ntp sorts itself out.
Here is a copy of my script called my_ufw.conf.sh
#!/bin/sh ####################################################################### # Run this script only once, to setup your UFW - uncomplicated firewall #######################################################################
# disable firewall ufw disable
# reset all firewall rules ufw reset
# set default rules: deny all incoming traffic, allow all outgoing traffic ufw default deny incoming ufw default allow outgoing
# open ports for Transmission-Daemon ufw allow 9091 ufw allow 20500:20599/tcp ufw allow 20500:20599/udp
# open port for GIT ufw allow 9418/tcp
# open port for network time protocol (ntpd) ufw allow ntp
# enable firewall ufw enable
# list all firewall rules ufw status verbose
Add the following incoming rules, using the In drop down menu option in gufw:
I don't think the added incoming rules are needed for NTP (which AFAIK only needs UDP port 123). I suspect its the "allow ntp" command that is solving the problem (assuming the 90 second start up issue was all because of NTP, and not due to some other services).
Anyway, I'm glad its sorted out. Thx for sharing your solution.
Having thought about it (more sub-consciously than anything) overnight, I think that what actually took away the problem was allowing all outgoing packets on the network. Which I did in the run once setup script - my_ufw.conf.sh
I haven't really looked at it yet, but I'm thinking that the restrictions that I'd placed on the outgoing packets weren't correct.
I had also allowed ntp both incoming & outgoing on port 123 using UDP, but there was that delay...
I guess I could test the theory by scrapping all the current rules & adding the previously mentioned rules via gufw making sure to allow all outgoing packets.
I guess I could test the theory by scrapping all the current rules & adding the previously mentioned rules via gufw making sure to allow all outgoing packets.
