Configuring Algo Server with NTP Daemon with firewalls to allow access only through the VPN tunnels.

[rampageservices]

Is your feature request related to a problem? Please describe.
In an attempt to limit outbound connections from the cloud to the outside world. One of the unknowns on a default configured chrony instance on a Linux computer is which NTP servers it will connect to. Generally these will be from a pool provided by the default distribution configuration.

Describe the solution you'd like
A configuration option to enable an NTP Daemon on the deployed cloud instance.

Describe alternatives you've considered
Using a separate dedicated server but it may be in the best interest of relative security to use the Algo server as the NTP server for local devices.

[dguido]

Implementation Plan for NTP Daemon Feature

I've researched this feature request and developed an implementation plan. Here's a summary:

Proposed Architecture

[Upstream NTP] --> [Algo Server (chrony)] --> [VPN Clients]
 (pool.ntp.org)     (local_service_ip:123)     (via tunnel)

The NTP server would follow the same architecture as DNS:

• Bind to local_service_ip (the same random 172.16.x.x loopback address used for DNS)
• Firewall rules restrict access to VPN subnets only
• Server syncs from configurable upstream NTP servers (default: pool.ntp.org)

NTP Daemon Choice: chrony

Why chrony over alternatives:

• Modern architecture, handles network changes gracefully
• Ubuntu default on 22.04/24.04
• Security features including rate limiting
• Lower memory footprint than ntpd

Note on memory-safe alternatives: ntpd-rs is a Rust-based NTP daemon backed by ISRG (Let's Encrypt). It's packaged for Ubuntu 24.04+ but not 22.04. Since Algo supports both, chrony provides consistency. Could revisit when 22.04 support is dropped.

Client Configuration: Documentation Only

I investigated auto-provisioning NTP to VPN clients:

• IKEv2/IPsec: The IANA IKEv2 Configuration Payload registry has no standard NTP server attribute (unlike DNS which has INTERNAL_IP4_DNS). Private-use attributes (16384-32767) could work but standard clients wouldn't understand them.
• WireGuard: No mechanism for pushing NTP configuration

Conclusion: Client NTP configuration must be manual, documented in docs/ntp.md.

Proposed Configuration

# config.cfg
ntp_enabled: false  # Disabled by default (Algo philosophy)

ntp_servers:
  - 0.pool.ntp.org
  - 1.pool.ntp.org
  - 2.pool.ntp.org
  - 3.pool.ntp.org

Security Layers

1. Firewall: -A INPUT -s {{ vpn_subnets }} -d {{ local_service_ip }} -p udp --dport 123 -j ACCEPT
2. Binding: chrony binds only to loopback alias, not public IP
3. AppArmor: Optional confinement profile
4. systemd hardening: NoNewPrivileges, ProtectSystem=strict, capability restrictions
5. Rate limiting: chrony's built-in ratelimit prevents amplification attacks

Files to Create/Modify

New files:

• roles/ntp/ - New role (tasks, templates, handlers, defaults)
• docs/ntp.md - Client configuration documentation

Modified files:

• config.cfg - Add ntp_enabled and ntp_servers
• server.yml - Import NTP role
• roles/common/templates/rules.v4.j2 - Firewall rule for port 123/UDP
• roles/common/templates/rules.v6.j2 - IPv6 firewall rule
• tests/unit/test_iptables_rules.py - Unit tests

Questions for Maintainers

1. Does this approach align with Algo's philosophy?
2. Any concerns about adding chrony as a dependency?
3. Should NTP server IP be shown in deployment output (same as DNS resolver)?

---

Full implementation plan available at: #14695

🤖 Generated with Claude Code

[dguido]

I'd prefer waiting until we upgrade the base image of Algo to a version with the ntpd-rs package.