Philips Hue Bridge Pro gebruikt vaste NTP-server in China

[xhal3]

Ik wil graag mijn bevindingen delen rondom het NTP-gedrag van de Philips Hue Bridge Pro en ben benieuwd hoe anderen dit hebben opgelost of ermee omgaan.

In mijn netwerk monitor ik uitgaand verkeer vrij strikt (IDS/IPS + geo-blocking). Daarbij viel op dat de Hue Bridge Pro elke ~17 à 18 minuten NTP-verkeer (UDP/123) genereert naar het IP-adres 203.107.6.88, wat geolokaliseerd is in China (Alibaba Cloud).

Ik heb dit verder onderzocht:

• Het betreft regulier NTP-verkeer (tijdssynchronisatie).
• Het IP-adres hoort bij Alibaba Cloud NTP.
• De bridge blijft dit verkeer herhalen als het geblokkeerd wordt.
• Via DHCP (Option 42) een eigen NTP-server meegeven heeft geen effect.
• DNS-override helpt ook niet als het IP hardcoded wordt gebruikt.

Zojuist heb ik hierover contact gehad met de Philips Hue / Signify servicedesk. Hun bevestiging:

• Het NTP-gedrag is niet configureerbaar.
• Het is niet mogelijk om een eigen NTP-server in te stellen.
• Het gebruik van deze NTP-server is onderdeel van de firmware en kan niet aangepast worden.

Functioneel snap ik dat het “onschuldig” NTP-verkeer is, maar vanuit netwerk- en security-oogpunt vind ik het toch ongemakkelijk:

• Verkeer naar China zonder configuratiemogelijkheid
• Geen regionale voorkeur (EU/NL)
• Geen ondersteuning voor enterprise-achtige netwerken met geo-blocking

Mijn vragen aan jullie:

Herkent iemand dit gedrag?

• Accepteren jullie dit en whitelisten jullie het verkeer?
• Redirecten jullie NTP (bijv. via firewall NAT naar een interne NTP-server)?
• Of blokkeren jullie het volledig en accepteren jullie eventuele tijd-drift?
• Zijn er mensen die dit met Pi-hole / firewallregels stabiel hebben weten op te lossen?

Ik ben vooral benieuwd naar praktische oplossingen die goed werken zonder dat je telkens firewalllogs vol ziet lopen.

Alvast dank voor het meedenken.

[Kixtart]

Dat deed de vorige bridge blijkbaar ook al: https://www.reddit.com/r/...ly_calling_back_to_china/ Wat meer inzichten daar mbt de traffic flow.

edit - extra resultaten
https://www.reddit.com/r/...bridge_constantly_trying/
https://www.reddit.com/r/..._to_chinese_time_servers/

[ Voor 52% gewijzigd door Kixtart op 15-12-2025 14:15 ]

[Ben(V)]

Tja weer een reden om geen gesloten system zoals Hue te gebruiken.
Als China besluit die NTP server stop te zetten hebben al die Hue bridges een probleem.

En een ntp server adress fixed in de firmware te bakken is natuurlijk te belachelijk voor woorden.

[FredvZ]

Het viel mij deze week ook op dat er continu verbinding wordt gezocht naar een ntp-server in China.

Ben(V) schreef op maandag 15 december 2025 @ 16:25:
Tja weer een reden om geen gesloten system zoals Hue te gebruiken.
Als China besluit die NTP server stop te zetten hebben al die Hue bridges een probleem.

Gelukkig maakt-ie ook gebruik van de DNS-server die je in je DHCP hebt geconfigureerd.
Ik heb nu op mijn firewall verkeer naar deze specifieke ntp-server geblokkeert. We zullen hoelang Hue het nog volhoudt. Al denk ik eerlijk gezegd dat-ie het gewoon blijft doen.

En een ntp server adress fixed in de firmware te bakken is natuurlijk te belachelijk voor woorden.

Het hoeft niet fixed te zijn natuurlijk. Kan ook best een setting zijn die ze met een update kunnen aanpassen.

[Ben(V)]

Hij blijft het gewoon doen op zijn eigen clock maar zijn niet meer gesynchroniseerd worden met een NTP clock en gaat dus op den duur verkeerd lopen.

Via DHCP een ntp server instellen werkt bijna nooit, dus ik betwijfel of die Hue Bridge dat wel doet.
Zou hij dat wel doen dan zou hij nooit naar een ntp server in China gaan, want dan zou hij de NTP server gebruiken die de dhcp server aanbied.

En ok dat te laten werken moet de dhcp server geconfigureerd zijn om een NTP server adres mee te geven en moet de ntp client (de HUE bridge) geconfigureerd zijn om dat te vragen en te gebruiken.
Die is dus zelden het geval.

Als het via een update van de firmware gaat is dat in mijn ogen fixed.
Je kunt het dan namelijk nog steeds niet zelf instellen.

[GarBaGe]

Je kan in je firewall dit NTP UDP verkeer toch onderscheppen en doorsturen naar een andere NTP server?
zoals dit:

code:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 123 -j DNAT --to 10.21.3.169:123

[FredvZ]

Ben(V) schreef op donderdag 15 januari 2026 @ 10:05:
Hij blijft het gewoon doen op zijn eigen clock maar zijn niet meer gesynchroniseerd worden met een NTP clock en gaat dus op den duur verkeerd lopen.

Zo te zien maakt de bridge standaard ook gebruik van time.google.com.
En dus ook van de NTP server die je eventueel met DHCP meegeeft.

Via DHCP een ntp server instellen werkt bijna nooit, dus ik betwijfel of die Hue Bridge dat wel doet.
Zou hij dat wel doen dan zou hij nooit naar een ntp server in China gaan, want dan zou hij de NTP server gebruiken die de dhcp server aanbied.

Blijkbaar hebben ze bij het ontwerpen ervoor gekozen om én de NTP-server die met DHCP meekomt te gebruiken én in de firmware zelf gekozen NTP-servers te gebruiken.

En ok dat te laten werken moet de dhcp server geconfigureerd zijn om een NTP server adres mee te geven en moet de ntp client (de HUE bridge) geconfigureerd zijn om dat te vragen en te gebruiken.
Die is dus zelden het geval.

Mijn ervaringen met NTP-serveradressen die met DHCP wordt meegestuurd zijn juist hartstikke positief, zowel zakelijk als privé

[pbeetje]

Klopt helemaal. Ik had het al veel eerder gelezen elders. Dat was een extra reden om over te stappen op een betere router dat meer grip houd op het netwerk verkeer. Dat is pfSense geworden met eigen keuze hardware. En inderdaad, bij het eerste experiment kwam de HUE onmiddellijk naar voren in de firewall logs. Alleen al frequentie van de NTP requests... opvallend veel per uur.

[Ben(V)]

Met een pfSense is het heel simpel om dat ntp verkeer van een fixed ip adres te rerouten naar een openbare ntp zoals 0.nl.pool.ntp.org of een eigen lokale ntp server.

[pbeetje]

Ben(V) schreef op woensdag 15 juli 2026 @ 11:14:
Met een pfSense is het heel simpel om dat ntp verkeer van een fixed ip adres te rerouten naar een openbare ntp zoals 0.nl.pool.ntp.org of een eigen lokale ntp server.

Inderdaad... met de stand van zaken op het internet de laatste jaren voldeed de oude Draytek echt niet meer. Met pfSense worden nu alle NTP requests naar de standaard poort omgeleid naar de interne NTP server (eigen GNSS). Evenals DNS, want veel, heel veel apparaten en applicaties hebben de neiging om andere DNS servers te willen gebruiken, al dan niet via DoT of DoH. Zeker daar waar Google, FaceBook of Chinese bedrijven bij betrokken zijn.

[ Voor 13% gewijzigd door pbeetje op 16-07-2026 07:17 ]

[icecreamfarmer]

pbeetje schreef op donderdag 16 juli 2026 @ 06:44:
[...]

Inderdaad... met de stand van zaken op het internet de laatste jaren voldeed de oude Draytek echt niet meer. Met pfSense worden nu alle NTP requests naar de standaard poort omgeleid naar de interne NTP server (eigen GNSS). Evenals DNS, want veel, heel veel apparaten en applicaties hebben de neiging om andere DNS servers te willen gebruiken, al dan niet via DoT of DoH. Zeker daar waar Google, FaceBook of Chinese bedrijven bij betrokken zijn.

Iemand die weet hoe je doet bij Unify doet?

[RedHead]

icecreamfarmer schreef op donderdag 16 juli 2026 @ 09:37:
[...]

Iemand die weet hoe je doet bij Unify doet?

Ben ik ook wel benieuw naar.

[Ben(V)]

Even gegoogled:

Configure Traffic Redirection: To ensure that devices (like smart home gadgets that hardcode public time servers) don't bypass this, you must apply a DNAT rule.

• You can add a rule on your UniFi Gateway via CLI/SSH using the following syntax for the redirection:
  
  iptables -t nat -A PREROUTING -p udp --dport 123 ! -s <YOUR_NTP_SERVER_IP> -j DNAT --to-destination <YOUR_NTP_SERVER_IP>:123

[ThinkPad]

Ik buig al het NTP-verkeer vanuit m'n IOT vlan om naar de interne NTP-server van OPNsense. Werkt prima, met een DNAT-rule idd.

Heb zo de regel niet bij de hand, maar volgens mij pakte ik alles dest != rfc1918

[ Voor 43% gewijzigd door ThinkPad op 20-07-2026 16:23 ]

[KroeT]

Ik heb toevallig net al dat verkeer geblokkeerd omdat ik het onprettig vond, met het risico dat Hue (de oude hub) straks matig gaat werken. Het omleiden is vermoedelijk verstandiger, dat moet ik maar eens proberen op de UDM Pro binnenkort.

[FredvZ]

KroeT schreef op woensdag 22 juli 2026 @ 22:07:
Ik heb toevallig net al dat verkeer geblokkeerd omdat ik het onprettig vond, met het risico dat Hue (de oude hub) straks matig gaat werken.

Om mezelf te quoten:

FredvZ schreef op woensdag 14 januari 2026 @ 20:15:
Gelukkig maakt-ie ook gebruik van de DNS-server die je in je DHCP hebt geconfigureerd.
Ik heb nu op mijn firewall verkeer naar deze specifieke ntp-server geblokkeert. We zullen hoelang Hue het nog volhoudt. Al denk ik eerlijk gezegd dat-ie het gewoon blijft doen.

Nu een half jaar verder werkt Hue nog steeds probleemloos.