Easy Time Sync

[BrandyWine]

Not sure if this is a bug on OPNsense, but when I had ntpd -q configued in gui and a time server that was nist ipv4 name, I was getting error that said "unable to resolve name" for that ipv4-only nist server. Seems odd because name lookup from the fw for that nist server was ok. My WAN is ipv4 ipv6 dhcp enabled, so I wonder if the ntpd -q was trying to find AAAA record, of which the nist ipv4 server did not have. I then changed the nist server in gui to use a ipv6 server and after apply I did not get any resolve error. That's curious.

I then just tried ntpdate with nist ipv6 server name and was successful. At that point is when I ditched using ntpd and just cron'd ntpdate.

[Patrick M. Hausen]

ntpd in regular operation as a local time source connected to one or multiple peers. So UDP 123, yes.

Actually in most of my locations I use the official time source of Germany - who encourage doing so - on one device, namely the Internet facing firewall, and then point all other servers at that. The official time source of course being 4 IPv4 and 4 IPv6 addresses and 4 different physical machines.


Internally then it's

server 192.168.1.1 iburst prefer

for every single server or VM or whatever runs on "Unix". Why not - this is how NTP was designed.


At home I have a stratum 1 because I was curious if these devices are any good (they are!):

https://centerclick.com/ntp/


Again common wisdom has been for decades to disable time sync from host to VM and run ntpd. That's what I'm doing everywhere - why not? ntpd does not use resources in an order of magnitude that would matter - at all. What do I gain by using your potentially less reliable method?

[BrandyWine]

ntpd in regular operation as a local time source connected to one or multiple peers. So UDP 123, yes

Again common wisdom has been for decades to disable time sync from host to VM and run ntpd. That's what I'm doing everywhere - why not? ntpd does not use resources in an order of magnitude that would matter - at all. What do I gain by using your potentially less reliable method?

Let me clarify.
I meant you run ntpd as resident daemon? If so this create listener port(s) on all ifaces by default. If others are not pointing to that server for time, then you don't need to run ntpd as resident daemon. You would use ntpd -q instead, but as far as I know, -q is the "run as client" switch, and it tells ntpd to quit after it's done, so you still need cron or the like to invoke it.

If ntpd is resident daemon and suddenly a 0-day exploit comes out, then your "everything" is suddenly exposed to that. My point was, if the system does not need a resident daemon service with listeners on the nics, then it should not be there. Min resources or not, if the service is not needed then it should not be run at all. Resident ntpd is different than ntpd -q

I would perhaps prefer code for ntpd to have another switch, something like ntpd -f, to tell ntpd to run as resident daemon but without any listeners, so basically a true real-time ntp client. Yes, you can restrict queries in conf file (restrict default ignore , restrict 127.0.0.1), we can also restrict listener to lo iface, but this still has resource-using udp/tcp listeners

Wow, that's a lot of ntpd config to setup and manage, yet I basically get the same thing with a short ntpdate in cron, hence the "Easy" in thread title.

Does OPNsense fw have anything that will crash if (if) the time stepped back? Do we care if OPNsense box is not -1+ nanosec accurate?

[Patrick M. Hausen]

I meant you run ntpd as resident daemon?

Yes, of course. It keeps the server's time and skews the clock so the deviation becomes less and less the longer the runtime. Persistent across reboots, because the information is kept in the drift file.

Yes, it creates listening sockets. So?

Code Select Expand

server <my local server in my data centre> iburst
restrict <my local server in my data centre> noquery nomodify notrap nopeer

restrict 127.0.0.1 nomodify notrap nopeer
restrict -6 ::1 nomodify notrap nopeer

restrict default ignore
restrict -6 default ignore

Done. If you have 2 or 3 servers as you should, add all of them. That's how you do it. Since ... don't remember.

[meyergru]

I use it as a definitive source for my network as well and distribute it via DHCP as the main NTP server to all local networks. This also would not work if only the local time of OpnSense was being synchronized via ntpdate.

[BrandyWine]

Yes, of course. It keeps the server's time and skews the clock so the deviation becomes less and less the longer the runtime. Persistent across reboots, because the information is kept in the drift file.

It's just me peeve.... socket is the connection, listener is just a place where sockets are formed.

For clarity (again), time sync for clients. cron ntpd -q still does the same thing as a resident ntpd, it will load in, run it's routine, update drift, adjust skew, adjust time, yada yada yada, then quit.

You kinda proving my point, you need to manage that restrict policy. Certainly not an issue for small non-dynamic environments.

But your NTP server is main source for local queries, so why then would the local queries (hosts devices etc) need to run full ntpd (resident daemon)? They would only need to run as clients (ntpd -q, or other).

Resident ntpd, "time server" (unless all the restricts make "time server" query-not-capable).
ntpd -q , not a time server, acts as client only, and is not using resources like resident daemons do.

Certainly an argument to make is, why not just cron ntpd -q, which of course can be done too, but a little more config is needed.

[Patrick M. Hausen]

You kinda proving my point, you need to manage that restrict policy. Certainly not an issue for small non-dynamic environments.

I am managing servers. Systems that run 24x7. Some of them hardware, some virtual. All of these run an ntpd ... because they can, because you run an sshd, an snmpd, ... etc.

ntpd -q exits. I want a time keeping service on my 24x7 running servers. It's a basic function of a system IMHO.

[BrandyWine]

I use it as a definitive source for my network as well and distribute it via DHCP as the main NTP server to all local networks. This also would not work if only the local time of OpnSense was being synchronized via ntpdate.

You use the fw as NTP server?
And agree, a time server needs resident ntpd (or the like) to be a time server. The context here however is just time sync for client. I set my OPNsense to query NIST time server, using ntpdate. No issues.

[meyergru]

Yes, because I want all machines in my network to have a definitive source, even if it were off by any amount of time. And I do not want to configure each client individually. OpnSense is pretty much the gateway for anyzhing internet-bound, be it as a reverse proxy, a central NTP or DNS server or an SMTP gateway.

With multiple VMs and containers, I lack the enthusiasm to configure all of them individually.

[BrandyWine]

ntpd -q exits. I want a time keeping service on my 24x7 running servers. It's a basic function of a system IMHO.

Again, I think you missed the point I was making.

If you had ntpd that could run w/o setting up any listeners, then that would make for a good NTP client, and you would not have to worry about restrict config and the like. For clients, technically ntpd does not need to stay running all the time. For unpredictable remote shell access, sshd does need to stay running all the time, unless you have a strict access policy, say 8am-5pm, and in that case I would cron to start sshd at 759am and then cron to stop sshd at 501pm. Most setups are "lazy", just leave everything running, even when it's not needed.

In your setup (for just your clients), I would cron ntpd -q to run hrs1 mins9. 

[Patrick M. Hausen]

You use the fw as NTP server?

Of course!

The firewall is the only system with a "full" Internet connection without NAT - at least for IPv4. And the system with the lowest latency, because it is connected directly to the uplink.

For a typical (non enterprise, redundant, super heavy ...) office network you run

- router (obviously)
- NAT (equally obvious)
- recursive DNS
- NTP
- DHCP (depends, maybe that goes to your Windows DC)

on the firewall system where it belongs. I have four decades of experience, consulted government agencies, am quite well known in the field - and I do not understand the question. What are you hinting at?

The firewall/router/NAT thingy is providing "Internet" to the office network. That means all services needed for "Internet" including a time source.

Checkpoint
Sidewinder
McAfee
...

Of course you do. It's the best place for the time service unless your network is way larger and you have multiple dedicated time serves, DNS servers etc.

[BrandyWine]

Yes, because I want all machines in my network to have a definitive source, even if it were off by any amount of time. And I do not want to configure each client individually. OpnSense is pretty much the gateway for anything internet-bound, be it as a reverse proxy, a central NTP or DNS server or an SMTP gateway.

With multiple VMs and containers, I lack the enthusiasm to configure alle of them individually.

Yes, but I would not make the fw the server. fw should just be a client. fw should just be doing fw. "UTM" was buzz word like "cloud" was. I myself want my fw to do fw work, and that's it. You could just install another free opnsense on a mini pc and use that on the LAN to provide all of the DHCP DNS NTP etc etc.

[Patrick M. Hausen]

fw should just be a client.

That does make sense. In a large data centre deployment I would agree with that. But in most setups the firewall is the Internet access server. And it runs all services necessary for that. Which other system is more qualified, more hardened, better monitored ... to do that?

[BrandyWine]

For a typical (non enterprise, redundant, super heavy ...) office network you run

- router (obviously)
- NAT (equally obvious)
- recursive DNS
- NTP
- DHCP (depends, maybe that goes to your Windows DC)

on the firewall system where it belongs.

What? That's NOT where those services (dhcp, ntp, dns) belong. That's the "UTM" model, and it's not a good one. You are hinting of a best practice to not allow hosts to reach out to internet directly, which is good sec practice. But never run non-fw services on a public facing fw device,..... if you want to be secure. If the OPNsense fw image can provide all the UTM services you need, then just install a 2nd one on the LAN, run all the non-fw stuff there. Sec-101.

[meyergru]

If I were to do that, I would not use OpnSense as the router/firewall at all. OpnSense's value lies in that it can do most fo the "gateway" work for sake of it being a full Unix-like machine. If I wanted to separate all of the services like DNS, DHCP and such out, there sure were some more specialised appliances for that, but frankly, those are more or less applicable in enterprise-grade installations, like Patrick said.

Then again, for small and medium businesses and home lab users, OpnSense alone does the trick and why should I convolute a fully working setup by using two OpnSense installations?

Also, for cloud-based setups, OpnSense does the trick on a VM host like Proxmox, where you cannot use any more specialised appliance or where you do not want to pay for that to happen.


But that discussion is way besides the point. YMMV, but for me, if I use OpnSense as the sole router, I still do not think using periodic ntpdate is a good idea, because:

1. If you want to have OpnSense as the LAN NTP server, it is outright impossible to use it like that.
2. I do not see any real performance benefit, because even on limited platforms, there is not much load with NTPD or Chrony.
3. There is a risk to have network services die or otherwise misbehave, should your time jump or - worse - even jump backwards. This is documented and I experienced it personally.

No need to fight back, you can do whatever you like. I just would not do it that way, period.