Firewalls & Network Access

This page explains, at a conceptual level, how to allow TelemetryOS devices to communicate through organizational firewalls. TelemetryOS uses modern, cloud-native infrastructure designed for reliability and scale. The practical implication is that devices initiate secure, outbound connections to TelemetryOS services over HTTPS, requiring traffic allowance based on hostnames—not static IP addresses.

What to Allow

TelemetryOS devices communicate outbound over TLS. In most environments, permitting secure egress to TelemetryOS hostnames is sufficient; no inbound rules from the public internet are required for device operation.

If your environment performs TLS inspection or proxies outbound HTTPS, ensure SNI/hostname-aware rules permit connections to TelemetryOS hostnames. DNS resolution must also be allowed so devices can resolve *.telemetryos.com at runtime.

Why We Don’t Publish IP Allowlists

In a modern cloud architecture, IP addresses change as a normal part of operating at scale:

• Elastic scaling and multi-region failover continuously adjust capacity and routing. The same hostname may resolve to different IPs over time or across regions.
• Content delivery networks (CDNs), DDoS protection, anycast routing, and managed services deliberately abstract static addressing to improve resilience and performance.
• Vendor infrastructure updates (security patches, capacity expansions, platform improvements) can shift underlying IP ranges without changing service availability or behavior.

Because of these dynamics, static IP allowlists for cloud SaaS are brittle. They break during routine scaling events, cause false outages, and require constant maintenance. Hostname- or SNI-based firewall rules align with how cloud services are delivered today and remain stable as infrastructure evolves.

Recommendations

Prefer hostname-aware controls at the network edge. Common patterns include:

• FQDN allowlisting: Permit outbound HTTPS to *.telemetryos.com using your firewall’s FQDN rules so new IPs are automatically permitted as DNS changes.
• SNI-based policies: If your proxy inspects TLS handshakes, allow by TLS Server Name Indication (SNI) for TelemetryOS hostnames.
• Egress proxy: If all outbound traffic flows through a corporate proxy, configure it to allow *.telemetryos.comand ensure websockets over TLS are supported.

These patterns keep security controls in place while avoiding brittle IP dependencies.

Operational Considerations

Give devices access to DNS so they can resolve TelemetryOS hostnames. Ensure outbound HTTPS on port 443 is not blocked or downgraded in ways that break modern TLS (for example, disabling required ciphers). If you use strict SSL inspection, exclude TelemetryOS device traffic or import the inspection root CA into the device trust store only if your organization’s policy permits and testing confirms compatibility.

Validation

A simple validation flow is often enough: place a device on the intended network segment, allow outbound HTTPS to *.telemetryos.com, and confirm that it can register, download content, and remain connected for real-time updates. Monitoring should show the device online and playing content reliably. If you see intermittent connectivity, review DNS, TLS interception, and SNI handling.