NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. DNS: IP → DNS → set *Servers*. CLI: /ip dns set servers=1.1.1.1,8.8.8.8
2. To also serve LAN clients: tick *Allow Remote Requests* — /ip dns set allow-remote-requests=yes
3. NTP: System → NTP Client → enable, set servers. CLI: /system ntp client set enabled=yes servers=pool.ntp.org
4. Timezone: /system clock set time-zone-name=Europe/London

Changed across versions

• 6.xNTP client and server are one menu, /system ntp client (with /system ntp client set enabled=yes mode=unicast primary-ntp=...), and there is no SNTP-server split.
• 7.xClient and server are separate: /system ntp client for syncing itself, /system ntp server for handing out time to others. The command shapes look similar but are distinct objects — v6 syntax pasted into a v7 box needs adjusting.

Gotchas & notes

• MikroTik devices without a battery-backed clock boot to 1970, which breaks HTTPS/certificate validation and makes log timestamps useless. Enabling the NTP client is not optional on RouterBOARD hardware.
• The NTP client itself needs DNS to resolve pool.ntp.org — but DNS may need working time for DoH. Use IP addresses for NTP servers to break that chicken-and-egg problem.
• allow-remote-requests=yes turns the router into an open resolver if your firewall permits UDP/53 from the WAN. Always pair it with an input chain drop rule for port 53 from outside.

Steps

1. DNS: Network → DNS → set Primary/Secondary, or use FortiGuard servers.
2. CLI: config system dns → set primary 1.1.1.1 → set secondary 8.8.8.8 → end
3. NTP: System → Settings → System Time → *Synchronize with NTP Server*, or use the FortiGuard default.
4. CLI: config system ntp → set ntpsync enable → set server-mode disable → end

Gotchas & notes

• FortiGate defaults to FortiGuard for both DNS and NTP, which works only if the unit has internet — on an isolated or pre-registration deployment, both silently fail and take licence validation with them.
• Bad time breaks FortiGuard licence checks, IPsec, SAML, and certificate validation and produces error messages that point nowhere near the clock. execute time and execute date are the first things to check on a misbehaving unit.
• Set the timezone under System → Settings; logs are stamped in the configured timezone and correlating with other devices gets painful if it is wrong.
• diagnose test application dnsproxy 3 shows which DNS server the unit is actually using and its response times.

Steps

1. Gateway/WAN DNS: Settings → Internet → <WAN> → *DNS Server* (auto from ISP or manual).
2. Per-network client DNS: Settings → Networks → <network> → *DHCP Name Server*.
3. NTP: Settings → System → Advanced → NTP Server (older versions: under Site settings).
4. Timezone: Settings → System → Timezone.

Gotchas & notes

• There are two separate DNS settings and mixing them up is common: the WAN DNS is what the gateway itself uses, and *DHCP Name Server* is what clients are told to use. Setting only one leaves the other on its default.
• The controller's time is what appears in the UI and events, and it takes it from the host OS on a self-hosted controller — not from the site NTP setting.
• Setting NTP to an internal server is important on isolated networks; UniFi devices default to Ubiquiti/NTP pool addresses and will report odd behaviour without internet.
• Timezone is per-site; a multi-site controller needs it set for each.

Steps

1. DNS: ip name-server 1.1.1.1 8.8.8.8 and ip domain lookup (plus ip domain name example.com)
2. NTP: ntp server 192.0.2.10 — optionally ntp server 192.0.2.10 prefer
3. Timezone: clock timezone GMT 0 (and clock summer-time rules if needed)
4. Verify: show clock detail, show ntp status, show ntp associations
5. Save: copy running-config startup-config

Gotchas & notes

• no ip domain lookup is standard practice on lab/production CLI devices because a mistyped command otherwise triggers a 30-second DNS lookup that you cannot interrupt easily. If typos hang your session, this is why.
• show clock detail tells you the time *source*. A leading * on show clock means the time is not authoritative — often unnoticed until certificates fail.
• NTP needs UDP/123 permitted both ways; an inbound ACL on the WAN blocking it leaves the clock drifting with no obvious error.
• Without valid time, SSH key generation, certificate enrolment, and any PKI-based feature (802.1X, WebAuth) fail with misleading errors.

Steps

1. DNS: Device → Setup → Services → *DNS Settings* → primary/secondary.
2. NTP: Device → Setup → Services → NTP tab → primary/secondary NTP server (authentication optional).
3. Timezone: Device → Setup → Management → General Settings → Time Zone.
4. Commit. Verify: show clock, show ntp.

Gotchas & notes

• These settings live on the management plane and are used for updates, licence checks, and log timestamps. They are separate from any DNS proxy you configure for users.
• A wrong clock breaks content/signature updates and certificate validation, and PAN-OS reports those as generic update failures. show ntp is a fast sanity check.
• With a *Service Route Configuration* (Device → Setup → Services → Service Route) you can send DNS/NTP out a dataplane interface instead of the management port — necessary when mgmt has no internet, and easy to overlook.
• Requires a Commit; the timezone change also affects how existing logs are displayed.

Steps

1. DNS: System → General Setup → *DNS Servers*; the *DNS Server Override* checkbox controls whether the WAN's DHCP-supplied servers win.
2. Resolver for clients: Services → DNS Resolver (Unbound) — enabled by default.
3. NTP: System → General Setup → Timezone, and Services → NTP for the server list and to serve time to clients.
4. Verify: Status → NTP, and Diagnostics → DNS Lookup.

Gotchas & notes

• DNS Server Override is the setting that confuses people: with it enabled (the default on some configs), the servers you typed in General Setup get replaced by the ISP's. Untick it if you want your entries to stick.
• By default the DNS Resolver runs in resolving mode, ignoring the DNS servers in General Setup entirely. If you want it to use those servers, enable *DNS Query Forwarding* — otherwise your configured upstreams are only used by the firewall itself.
• pfSense serves NTP to clients by default on some versions; restrict it with firewall rules rather than assuming it is closed.
• Diagnostics → DNS Lookup shows the result from each configured server side by side — the quickest way to spot one bad resolver.

Steps

1. GUI — device DNS: MANAGE → Network → DNS → enter up to three DNS Server addresses the appliance itself uses for lookups (license checks, FQDN address-object resolution, signature/update servers). This is separate from any DNS handed out by a DHCP scope.
2. GUI — device NTP: MANAGE → System Setup → System → Time (plain System → Time in SonicOS 6.5) → enable Set time automatically using NTP → either accept SonicWall's built-in default NTP server list or add your own server(s) → set the correct Time Zone.
3. CLI (partial, DNS only): the appliance's own DNS servers can be set from the SSH/console E-CLI during basic setup, per the SonicOS CLI Reference Guide's configuration-mode commands — but there is no equivalent CLI command for NTP servers.
4. Verify: System → Time page shows current synced time/status; DNS health shows indirectly via successful signature updates or working FQDN address objects.

Changed across versions

• 7.0SonicOS 7's UI reorganization moved Time from a top-level System menu into MANAGE → System Setup → System → Time; the underlying NTP behavior is unchanged from 6.5.

Gotchas & notes

• This is a different setting from the DNS servers a DHCP scope hands to clients — plenty of admins only ever touch the DHCP scope's DNS fields and never notice the firewall's own resolver is unset or wrong.
• Bad device DNS fails silently: FQDN-based address objects stop resolving and security-service signature/license updates quietly go stale, with no banner pointing at DNS as the cause.
• Bad device time is the classic hidden cause of 'VPN tunnel won't come up' and 'certificate invalid' errors — IKE negotiation and any cert validation (GUI login cert, DPI-SSL CA) are time-sensitive and give no hint that NTP is the actual problem.
• NTP configuration is GUI-only — there's no E-CLI command to add or change NTP servers, consistent with the CLI being reserved for bootstrap network setup and diagnostics rather than mirroring every System Setup screen.

Steps

1. Router/Orbi Pro's own DNS (what the box itself uses for lookups, cloud check-in, DDNS — distinct from what it hands to LAN clients): Insight portal → Devices → [router] → Internet/WAN Settings → DNS defaults to Get Automatically (from ISP); switch to Use These DNS Servers and enter Primary/Secondary manually if needed. This is a separate field from the DNS you set under LAN/DHCP for clients — easy to edit the wrong one.
2. Router/Orbi Pro's own NTP/clock: there is no user-facing NTP server field in Insight. The only exposed control is Device → General Settings → Time Zone; the device syncs its own clock automatically against NETGEAR's cloud infrastructure on check-in. You cannot point it at a private/internal NTP server — this is a real capability gap, not something buried deeper in the menus.
3. Smart Switches (local per-device GUI): System → Time (SNTP) — enable the SNTP client, choose broadcast/unicast mode, enter a server IP/hostname; System → IP/Network Settings has the switch's own DNS field (used for name resolution in things like syslog-by-hostname). The Lite CLI's coverage of these settings is inconsistent across firmware — some builds only let you view state (show sntp-style), not configure it.
4. M4200/M4300 (console or SSH, real CLI): configure → sntp client mode unicast → sntp server <ip-address>, plus clock timezone <hour> <minute> (or the equivalent System → Time GUI page). DNS is set via System → DNS in the GUI, or in CLI via the ip name server/ip domain command family — confirm exact keyword with ? since it varies slightly across 12.0.x firmware.

Gotchas & notes

• The sharpest edge of the three-surface split: on a router or Orbi Pro AP you cannot set a custom NTP server at all. If you need the box's clock pinned to an internal time source before deploying certs or a site-to-site VPN, Insight-managed routers/APs simply can't do it — Time Zone is the only lever you get.
• The WAN/Internet DNS field (the device's own resolver) is entirely separate from the DNS you hand out to DHCP clients under LAN settings — changing one does not touch the other, and that split is a common root cause of 'I fixed DNS but the VPN certificate check still fails' tickets.
• Switch-side SNTP/DNS settings are per-device and are NOT pushed or synced through Insight even when the switch is Insight-managed — Insight there manages VLANs/ports/PoE, not the switch's own clock or resolver, so each switch has to be touched individually via its local GUI or CLI.
• Don't assume the Smart Switch Lite CLI can do everything its local web GUI can for time/DNS — it's deliberately stripped down, and several commands that exist on the M4200/M4300 CLI aren't present there at all.