# Using a Port Scanner to Validate Hexnode UEM Network Connectivity At a Glance ----------- In a UEM environment, a pending command usually indicates that the endpoint has not yet acknowledged, received, or reported completion of the command. The cause may be network-layer blocking, device offline state, OS throttling, push notification delay, or platform-specific restrictions. Hexnode UEM relies on outbound device connectivity to Hexnode cloud services and platform notification services such as APNs, FCM, WNS, and MQTT. These services help wake devices or notify them to check in with Hexnode for pending commands, policies, or actions. A **port scanner** is a critical diagnostic tool used to test these precise network pathways, verifying whether a local firewall, web proxy, or ISP is silently dropping required traffic. Rather than guessing why a fleet is unresponsive, IT administrators use port scanning to validate whether an endpoint can successfully resolve hostnames and reach necessary cloud infrastructure. This guide details how to leverage port scan results to troubleshoot network-layer blocks, validate security rules, and restore Hexnode connectivity across your enterprise. > **Note:** Port scanning is a network-layer diagnostic. It helps prove whether required pathways are reachable, but Hexnode command execution also depends on device state, enrollment, push services, certificates, permissions, OS restrictions, and action-specific prerequisites. What a Port Scanner can and cannot Prove ---------------------------------------- A port scan is an invaluable diagnostic step, but it must be interpreted correctly. It validates network reachability, not OS-level application behaviors. Admin QuestionCan a Port Scanner Answer It?Technical Explanation**Is the firewall blocking APNs/FCM/WNS/MQTT ports?**Yes, partlyIt can test whether specific ports are reachable from the test network.**Is DNS resolving correctly?**PartiallyUse nslookup, dig, or Resolve-DnsName for proper DNS validation.**Why does Remote View fail?**PartiallyIt can test STUN/TURN reachability, but not permissions, NAT behavior, session state, or endpoint readiness.**Is SSL Decryption breaking traffic?**No/PartiallyA port scan shows TCP reachability, not TLS trust integrity. Use TLS/certificate testing and proxy logs.**Is the OS ignoring the push token?**NoPort scanning cannot diagnose OS sleep, token state, app throttling, or battery optimization.Hexnode-Specific Port Validation Matrix --------------------------------------- When troubleshooting device unresponsiveness, do not test blindly. Map the symptom directly to the required cloud infrastructure protocol. ProblemWhat to ValidateWhy it Matters**Devices are not enrolling**HTTPS (TCP 443), DNS (TCP/UDP 53)The absolute baseline required for portal reachability, identity validation, and profile downloads.**Android commands stay pending**FCM (TCP 5228, 5229, 5230, 443), MQTT (TCP 1883, 8883)Required to wake Android devices from sleep and trigger continuous sync via Hexnode’s broker.**Apple devices do not receive commands**APNs (TCP 5223, 443)Apple devices require a persistent APNs connection over 5223 to listen for MDM wakeups.**Windows commands fail**WNS (TCP 443)WNS uses TCP 443 to deliver notifications. After notification, the Windows device checks in with Hexnode to retrieve tasks or commands.**Remote View fails to connect**STUN/TURN (TCP/UDP 3478, 5349)WebRTC requires these specific ports for NAT traversal and screen stream relay between endpoint and portal.Network Vantage Point: Where to Run the Scan -------------------------------------------- A massive administrative blind spot is testing from the wrong network layer. A successful scan from an IT administrator’s unlocked laptop does not reflect the reality of a restricted kiosk endpoint. You must scan from the exact vantage point of the failing device. Device/Network ScenarioRequired Validation Point**Corporate Wi-Fi (SSID)**Run the scan from a test device connected exactly to that specific SSID and VLAN.**Kiosk or Warehouse VLAN**Scan directly from the restricted subnet, not the privileged IT admin subnet.**Remote User on Corporate VPN**Scan with the VPN client active to test split-tunnel routing and gateway restrictions.**Cellular-only Endpoints**Cellular-only endpoints: test over the same carrier connection to identify carrier filtering, captive portal behavior, APN restrictions, or blocked outbound ports.**Technician to Endpoint (Remote View)**Validate STUN/TURN ports from both the admin’s viewing machine and the target endpoint.Operational Troubleshooting Workflow ------------------------------------ When a Hexnode action fails, follow this structured workflow to isolate the network variable: 1. **Identify the Failed Action:** Determine if the failure is platform-specific (e.g., only Apple devices failing points to APNs) or universal (points to baseline HTTPS/DNS). 2. **Match to the Port Matrix:** Identify the required ports (e.g., 5228 for FCM, 5223 for APNs) using the validation matrix above. 3. **Execute from the Correct Vantage Point:** Use a port scanner (like nmap, Test-NetConnection, or Network Utility) from a device on the exact same network segment as the failing endpoint. 4. **Validate Outbound-Only Traffic Paths:** Ensure you are testing outbound connections to Hexnode domains. UEM architectures do not require inbound firewall ports to be opened. 5. **Check for Proxy/SSL Decryption:** If the port is open but the device remains offline, verify if your firewall is performing Deep Packet Inspection (DPI) or SSL Decryption. TLS inspection or certificate substitution can break platform notification services because devices and services expect trusted end-to-end TLS sessions. 6. **Verify Hostname Resolution:** Run nslookup on the endpoint to ensure the network’s DNS server is successfully resolving Hexnode and OEM notification domains. “Port Open But Hexnode Still Failing” Diagnostics ------------------------------------------------- Network administrators often fall into the trap of over-trusting a clean port scan. If the scanner shows green but the UEM action still fails, investigate these hidden causes. SymptomHidden Cause**Android ignores FCM pings**Android commands stay pending even though FCM ports are reachable. The device may be offline, restricted by OEM battery optimization, missing required app permissions, or unable to run the Hexnode agent reliably in the background.**Apple device stays pending**The device may be offline, unable to reach APNs, not checking in, affected by push-token/certificate issues, or delayed by OS/network state.**App deployment stuck at “Pending”**The network is fine, but the VPP or Managed Google Play license is missing, unallocated, or facing a regional mismatch.**UI errors despite open TCP 443**CDN/CloudFront regional IP variances are being blocked by strict, outdated firewall IP allowlists.Defensive Scanning Bounds & Glossary ---------------------------------------- **Defensive Boundary:** Port scanning in a UEM troubleshooting context is strictly defensive. You are validating authorized outbound communication lines to known Hexnode and OEM infrastructure. Avoid aggressive or broad scanning against third-party or Hexnode-owned infrastructure. Limit testing to authorized connectivity checks for required ports and domains, and coordinate with your security/network team if deeper testing is required. ### Glossary Matrix TermDefinition**Port Scanner**A software tool used to probe a network endpoint or server to determine if a specific data port is open, closed, or filtered.**TCP / UDP**TCP (Transmission Control Protocol) ensures reliable, ordered delivery. UDP (User Datagram Protocol) prioritizes speed over reliability (critical for Remote View STUN/TURN).**Outbound vs. Bidirectional**UEM requires devices to reach out to the cloud (Outbound). You do not need to open inbound ports mapping the internet to your devices.**DNS Resolution**The process of translating a domain name (hexnode.com) into a machine-readable IP address.**Allowlist**An explicit list of permitted domains or IPs in a firewall designed to block all other traffic.**Push Notification Service**OEM infrastructure (APNs, FCM, WNS) used to send lightweight “wake up” signals to dormant devices.