Our team could not access our Hexnode environment from the corporate office network. The concern was that our office public IP range might have been blocked or flagged somewhere on the Hexnode side. Has anyone seen this before, and what is the best way to confirm whether it is actually an IP block or a routing issue?
Hexnode portal not accessible from office network: suspected IP blockingSolved
Replies (4)
Hi @ryanmoore,
If the Hexnode portal is inaccessible only from a specific office network, start by separating a possible Hexnode-side block from local or upstream network routing issues.
Recommended checks:
- Confirm whether the issue is limited to one network
- Test access from another network, such as a mobile hotspot or a different office location.
- If the portal loads elsewhere, the issue is likely tied to the affected network path.
- Check browser-level errors
- Open the browser developer tools and review the Console and Network tabs while loading the portal.
- Look for HTTP errors, DNS failures, TLS errors, blocked requests, or connection timeouts.
- Run basic network diagnostics from the affected network
- Use
pingto check basic reachability. - Use
tracerton Windows ortracerouteon macOS/Linux to identify where the connection fails.
- Use
- Review local network controls
- Check whether a firewall, proxy, secure web gateway, DNS filter, or recent network change is blocking outbound access.
- Compare with Hexnode-side blocking
- If there is no block or flag on the Hexnode side and the traceroute shows failure before reaching the destination, the issue is usually with the corporate network path or upstream ISP routing.
In this type of case, the most useful indicator is whether the failure occurs consistently from the affected office IP range while other networks can reach the portal normally.
Best Regards,
Isabel Lora
Hexnode UEM
We had our network team run a few more checks. They found that the issue was not with Hexnode blocking the IP range. It looked like the traffic was failing somewhere with the upstream ISP/routing path from our office network.
That matches what we saw once. The portal itself was fine, but one office could not reach it because of an ISP routing problem. Traceroute helped prove the traffic was dropping before it got anywhere useful. Once the ISP corrected the route, access came back without changing anything in Hexnode.
Correct @sarahmiller. If Hexnode has not blocked the IP range and the diagnostics point to a failed route outside the local network, the next step is to escalate the route failure to the ISP or network provider.
A practical ISP escalation should include:
- The affected public IP range or office network range.
- The Hexnode portal URL being accessed.
- The traceroute output showing where the route stops or times out.
- Confirmation that the same portal is reachable from other networks.
- Any browser error or connection timeout details observed from the affected network.
No Hexnode policy or portal configuration change is required when the root cause is upstream ISP routing.
Best Regards,
Isabel Lora
Hexnode UEM