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é