"Jeff Boyce" wrote in message
news:001901c6c318$b03f2ec0$6970a8c0@jeff...

> I am hoping that someone can explain to me what I need to add or
> change to my firewall settings to allow ntp to synchronize to an
> outside time source.


> My objective is to have a server in my office synchronize to an
> outside time server, ...

> My general network setup is a dsl line coming into an ActionTec
> dsl modem gateway doing NAT.

Okay. I'm going to work from what I understand from the above: you
have an NTP server with external connections behind a NATting gateway.

The server must talk to its external associations. Allow it to send
from UDP/123[0] to UDP/123, and to receive the replies[1]. You can
limit this to only the servers it should talk to if you are feeling
paranoid. This does not play nice with dynamic schemes, though, in
particular the pool.

The gateway must allow this traffic. If the rule is to allow and NAT
all traffic from inside to outside, it already will.

The clients must talk to the server. So it must accept NTP traffic
(UDP/123[0] to UDP/123 again), and reply.

My own configuration is slightly different because the primary NTP
server is _on_ the gateway, and I use ipchains. It basically looks
like this:

ipchains -A input -i ppp0 -p udp -s 123 -d 123 -j ACCEPT
ipchains -A output -i ppp0 -p udp -s 123 -d 123 -j ACCEPT

ppp0 is the Internet-facing interface; are ntp-[a-d].xs4all.nl,
my ISP's NTP servers (named that only through a hosts file), is
kittensandcats.xs4all.nl, my public IP address (on ppp0), and NTP traffic
between the gateway and those four NTP servers is allowed.

Perhaps more useful are the following lines left over from the time when
my secondary internal NTP server still used the pool:

ipchains -A forward -i ppp0 -p udp -s 123 -d class-A/1 123 -j MASQ
ipchains -A forward -i ppp0 -p udp -s 123 -d class-B/2 123 -j MASQ
ipchains -A forward -i ppp0 -p udp -s 123 -d class-C/3 123 -j MASQ

is ntp1.kittensandcats.net, the secondary internal NTP server,
class-[ABC] are network ranges of public unicast IP addresses (also from
the hosts file), and NTP traffic from the server to most everywhere
outside is allowed - note that MASQing automagically un-transforms traffic
recognised as return traffic.

Groetjes,
Maarten Wiltink

[0] By default, an NTP client will talk (UDP) _from_ port 123. This
can be reconfigured to use unprivileged ports.
[1] Most firewalls can pretend a UDP exchange is a connection, and
allow replies to the initial query with a single setting.

Jeff Boyce wrote:

> Greetings -
>
> I am hoping that someone can explain to me what I need to add or change
> to my firewall settings to allow ntp to synchronize to an outside time
> source. An example would be great, an explanation with the example would
> be super. My objective is to have a server in my office synchronize to
> an outside time server, then the desktop PC's would synchronize to the
> server. I have the desktop PC's configured properly, but my server is
> not communicating to an external time server. I would like to fix this
> as my server looses almost 2 minutes a month. I have read all the
> documentation on configuring ntp and have followed the discussions on
> this list for the past few months. I believe that ntp would work
> properly if I had the right firewall setting. I can give additional
> information on how I came to this conclusion if necessary.
>
> My general network setup is a dsl line coming into an ActionTec dsl
> modem gateway doing NAT. The dsl gateway has a simple firewall
> configuration utility which is set to allow ntp through. The gateway is
> then connected into my network switch (Dell 24 port unmanaged switch) in
> which my server (Dell PE2600) is also connected. The server is running
> RHEL 3, completely up to date. It appears that the IPtables rules on
> the server is blocking the ntp communication. Do I need to have both an
> INPUT and OUTPUT rule in iptables, or just one of these? I searched
> through the ntp.org site and could not find any firewall examples.
> Other google searches turned up a lot of conflicting information, some
> indicated that I did not need an INPUT rule because I am not a time
> server to the public. I want to be careful about changing my iptables
> as I understand I could cause more problems not knowing exactly what I
> am doing. My current iptables rules are pretty basic since we rely on
> the gateway firewall. I can forward a copy of my iptables rules to
> someone willing to help me, but did not want to post it publicly. If
> anyone can provide a firewall rule example and an explanation of the
> rule I would appreciate it. Thanks.
>
> Jeff Boyce
> www.meridianenv.com
>
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
>

The stock RHEL 3 comes with an old version of nptd and a script that
starts it. That script makes changes to the firewall to allow NTP when
it starts. When the script shuts it down the firewall is restored. You
don't have to use the antique ntpd but you do have to use the script
unless you know enough to successfully tinker with the firewall.

The documentation for the firewall appears to have been written for
someone who already knows a great deal about it!!!

>My general network setup is a dsl line coming into an ActionTec dsl modem
>gateway doing NAT.

In addition to IPTables on your server, you may have to configure
your NAT box to forward outside packets to UDP port 123 at your
external IP address to your NTP server. It probably depends
on the fine print of your NAT box. If a packet arrives for port 123,
does it assume a low port number is for a server and check the server
forwarding table, or does it look in the reply mapping table?

You can test the IPTables rules by poking your server
from inside your firewall with ntpq.


--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.