Edge Connectivity and Local Network Issues
Troubleshoot common local network issues that may cause the Edge device to disconnect or show unstable connectivity.
| Scenario or error | Likely meaning | Recommended next steps |
|---|---|---|
| Firewall, web filter, or security gateway is in the traffic path | A security appliance between the Edge device and the internet may be interfering with the connection. | Confirm whether there is a firewall or gateway such as Fortinet, Palo Alto, Check Point, Sophos, SonicWall, Cisco, Meraki, Zscaler, Netskope, or Cloudflare Gateway between the Edge device and the internet. |
| SSL / TLS inspection, HTTPS decryption, or DPI is enabled | Traffic inspection may be breaking or interfering with the long-running secure connection to Xyte cloud. | If any of these features are enabled, add *.xyte.io and specifically eu1.edge.xyte.io to the bypass / exclusion list so this traffic is not inspected. |
| Outbound idle-connection timeout is too short | The firewall or router may be closing long-running secure TCP / HTTPS connections after a few minutes of inactivity. | Check whether there is an outbound idle-timeout setting. If so, increase it to at least 1 hour for traffic to *.xyte.io, or exempt that destination from the timeout. |
| NAT / shared public IP exhaustion | If many devices share the same public IP, the firewall may occasionally run out of outbound ports under load. | Check firewall logs for messages such as NAT pool exhausted, no source port available, or similar, and share them if found. |
| DNS resolution may be inconsistent | DNS for eu1.edge.xyte.io may be returning different or unexpected addresses. | From the Edge device network, run the lookup several times and confirm whether the result stays consistent. Windows: nslookup eu1.edge.xyte.io Mac/Linux: dig eu1.edge.xyte.io or host eu1.edge.xyte.io |
| Host clock / time sync issue | If the host clock is inaccurate, or NTP is blocked, secure connections may fail intermittently. | Confirm that the host clock is accurate within a few seconds of real time and that outbound NTP traffic is not blocked. |
The Edge stores a single address per device and uses it both for the ICMP status check and for any protocol polling. It must be the device's own IP address, reachable by Layer-3 routing from the Edge host, with ICMP echo permitted.
Address translation is not supported. Pointing the Edge at a router, control processor, or jump host that NATs or port-forwards to the device — for example a Crestron CP4N Control Subnet port mapping — does not work:
- ICMP has no port, so a port mapping cannot carry the status check.
- The pings are answered by the intermediary, not the device. Every device behind it reports online for as long as the intermediary is up, and a powered-off or failed device never raises an incident. The claim-time reachability check also passes on the intermediary's reply, so the misconfiguration is accepted silently rather than reported as an error.
Symptom to look for: several devices that share one upstream appliance are permanently online with near-identical response times, and go offline together.
Resolution: confirm each device is claimed with its own IP address, routed and pingable from the Edge host. If the devices sit on an isolated subnet that can only be reached through NAT (such as a Crestron control subnet), deploy an Edge inside that subnet — on a dual-homed host, or on a dedicated host/VM on the isolated side. The Edge needs outbound access only, so no inbound rules or mappings are required. Note that a host can run only one Edge agent.
Monitoring devices across multiple subnets
A single Edge can monitor devices on multiple subnets as long as Layer-3 routing gives the Edge host ICMP reachability to each device's native IP address. The Edge monitors by IP address — it does not need to be physically or logically attached to the same broadcast domain as the device.
For example, if a site has several Crestron CP4N processors, each creating a separate 172.22.x.x Control Subnet, one Edge can reach devices across all of them provided that:
- Layer-3 routing is configured between the Edge host and each Control Subnet (not NAT — see above).
- ICMP echo is permitted end-to-end to each device's own IP.
If Layer-3 routing between subnets is not feasible, deploy a separate Edge inside each isolated subnet. The Edge is a Docker container and can run on a VM or any host that meets the machine requirements — no dedicated physical appliance is needed.
Updated 4 days ago