Captive Portals - Operational
Captive Portals
Admin Interface - Operational
Admin Interface
Notice history
View current statusAug 2026
- Resolved · UTC
This network incident has been resolved, a faulty network device has been replaced.
If you use Cloudi-Fi 802.1x service, please make sure you update your configuration to use our new DNS endpoints.
We apologize for any inconvenience caused and appreciate your understanding. - Identified · UTC
An identified network incident is affecting our radius 802.1x service and should be soon resolved.
As fallback and to make our radius availability more robust, we recommend our customers to update their 802.1x radius configuration to use these new DNS endpoints :
Please make sure these Cloudi-Fi radius IPs are allowed on your firewalls (UDP/1815) :178.32.123.138
5.135.94.202
164.132.247.209
91.134.58.235
Jul 2026
- Resolved · UTC
Following continued investigation with Zscaler support, the authentication flow has remained stable during repeated validation tests.
The previously observed symptoms, including blank captive portal pages, authentication errors, and abnormal authentication delays, have not been reproduced during the latest tests.
The service is therefore considered stable and the incident will now be closed.
Should similar symptoms occur again, a new investigation will be initiated and the corresponding authentication traces will be collected for further analysis.
- Investigating · UTC
Description of the Anomaly
When a device re-enters the captive portal flow while its previous session is still active, a new authentication token is generated for the same IP address and site instead of reusing the existing valid session. This behavior has contributed to the authentication delays observed by end users.Investigation Status
Following investigation with Zscaler support, it was confirmed that the issue stems from latency in the backend infrastructure during authentication validation. In the test case analyzed, the response from login.zscaler.net was delayed by approximately 28 seconds.
This delay causes the captive portal browser on iOS and Android devices to time out before the authentication flow can complete. Although authentication is ultimately validated in the background, it occurs too late for the portal window to close as expected, resulting in a degraded experience for end users.Action Plan
We continue to work closely with Zscaler support to determine the root cause of this backend latency and identify a permanent resolution.
In the meantime, we have implemented a mitigation measure related to the authentication process: it will now be triggered less frequently, reducing how often guests encounter the 28-second delay.
We will share further updates as soon as additional information becomes available.

