Skip to content
English
  • There are no suggestions because the search field is empty.

 Troubleshooting HTTP, HTTPS, and RDP Access Issues in the Remote Access (RA) Portal

This document serves as a guide to resolve access issues HTTP, HTTPS, or RDP devices through the Remote Access (RA) Portal.

1. Verify the Netpulse Service in Secure Edge (SE)

  1. Log in to the Secure Edge (SE) Portal.
  2. Navigate to the appropriate Organization and select the relevant Site.
  3. Click the Services tab on the Site Node.
  4. Verify whether the Netpulse service is available and configured on the site.
  5. If the Netpulse service is not configured, follow the provided SOP link( How to deploy Netpulse ) to configure the service.
2. Configure a Netpulse Device in the RA Portal
  1. Log in to the appropriate Remote Access (RA) Portal.
  2. Click the Devices icon in the left-hand navigation panel.
  3. Under the Devices tab, click the + (Add) icon on the right-hand side.
  4. Select the appropriate Site.
  5. Enter the following details:
    • Service IP: Enter the Netpulse Service IP configured in the Secure Edge Portal.
    • Hostname: Enter a suitable hostname for identification.
    • Description: Use Netpulse - <Site Name> to make the device easy to identify.
  6. Save the device configuration.
  7. Once the device is created, open the HTTP Netpulse connection.
3. Verify Network Connectivity Using Ping
  1. Navigate to the Ping Check tab.
  2. Enter the IP address of the target device to verify network connectivity.
  3. Execute the ping test using the following command:ping <Target IP Address>
  4. Review the results to determine whether the target device is reachable and whether packet loss or intermittent connectivity is present.

Expected result: The target device should respond consistently without packet loss. If packet loss or timeouts occur, investigate the network connectivity between the Netpulse service and the target device.

4. Verify Port Accessibility Using Nmap
  1. Navigate to the Nmap tab.
  2. Enter the target device IP address and the port associated with the service being tested.
  3. Execute the Nmap command using the following format:nmap -p <Port> <Target IP Address>
  4. Review the scan results to determine the port status.

Port status interpretation:

  • Open: The target port is accepting connections.
  • Closed: The target is reachable, but no service is listening on the specified port.
  • Filtered: A firewall or another network restriction may be preventing Nmap from determining whether the port is open or closed.
5. Troubleshooting Based on Results
  • If the ping test fails, investigate network connectivity, routing, and firewall rules.
  • If the ping test succeeds but the required port is closed, verify that the service is running and listening on the target device.
  • If the port is filtered, review firewall policies and network access rules between the Netpulse service and the target device.
  • If ping and port checks are successful but the error page persists in the RA Portal, investigate the HTTP/HTTPS/RDP connection configuration and the relevant service logs.
6. Validation

After completing the troubleshooting steps, retry accessing the target device through the RA Portal using the appropriate HTTP, HTTPS, or RDP connection. Confirm whether the error page has been resolved.

 7. Local Troubleshooting at the Site

As an alternative to troubleshooting through the RA Portal, to perform the following checks locally from a computer connected to the same network as the target device.

Step 1: Verify Device Reachability

  1. Open Command Prompt on a Windows computer.
  2. Execute the following command:ping <Target IP Address>
  3. Verify whether the device responds consistently.
  4. Check for request timeouts or packet loss.

Expected result: The target device should be reachable without intermittent packet loss, provided ICMP traffic is permitted by the network.

Note: Some devices block ICMP traffic. A failed ping does not necessarily mean the device is unavailable.

Step 2: Verify HTTP/HTTPS/RDP Port Connectivity

  • Open PowerShell on the local computer.
  • Run the appropriate command for the service being tested.
  • HTTP (Port 80):Test-NetConnection <Target IP Address> -Port 80
  • HTTPS (Port 443):Test-NetConnection <Target IP Address> -Port 443
  • RDP (Port 3389):Test-NetConnection <Target IP Address> -Port 3389
  • Check the TcpTestSucceeded result.

Result interpretation:

  • True: A TCP connection to the specified port was successful from the local computer.
  • False: The connection failed. Check the target service, routing, firewall rules, and port configuration.

Note: Use the actual configured port if the device uses a non-standard port.

Step 3: Verify HTTP/HTTPS Access Through a Browser

  1. Open Microsoft Edge or another supported browser on the local computer.
  2. Enter the target device's URL or IP address.
    • HTTP: http://<Target IP Address>
    • HTTPS: https://<Target IP Address>
  3. Verify whether the device's web interface loads successfully.
  4. If an error appears, capture a screenshot and record the exact error message.

For HTTPS, a certificate warning may indicate a certificate trust or hostname mismatch rather than a network connectivity issue.

Step 4: Verify RDP Access Locally

  1. Press Windows + R.
  2. Enter mstsc and press Enter.
  3. Enter the target device's IP address and, if required, the configured RDP port.
  4. Attempt to establish the RDP session.
  5. Record any connection error or authentication failure.

If RDP fails locally, verify that Remote Desktop is enabled on the target device, the RDP service is running, and the appropriate firewall rule allows connections.

Step 5: Verify Local Network and Firewall Configuration

If the tests fail, ask the customer's network team to verify:

  • The target device's IP address, subnet mask, and default gateway.
  • Connectivity and routing between the local computer and target device.
  • Firewall rules permitting the required TCP ports.
  • Whether network segmentation, VLANs, or access control lists restrict connectivity.
  • Whether the relevant HTTP, HTTPS, or RDP service is running and listening on the target device.

8. Troubleshooting Based on Results

  • Ping fails locally and through Netpulse: Investigate target device availability, routing, and network restrictions. Confirm whether ICMP is permitted.
  • Ping succeeds, but the required TCP port fails: Verify that the service is running, listening on the correct port, and permitted by the firewall.
  • Local access succeeds, but RA Portal access fails: Focus on the Netpulse service, RA Portal connection configuration, and the network path between Netpulse and the target device.
  • Local access and Netpulse connectivity checks succeed, but the error page persists: Investigate the RA Portal connection configuration, authentication, and relevant service logs.

9. Validation and Escalation

  1. Retry accessing the target device through the RA Portal using the appropriate HTTP, HTTPS, or RDP connection.
  2. Confirm whether the issue has been resolved.
  3. If the issue persists, collect the following information:
    • Target device IP address and service port.
    • Ping test results from the RA Portal and the customer's local network.
    • Nmap results from Netpulse.
    • PowerShell Test-NetConnection results from the local computer.
    • Screenshots of the error page and any browser or RDP error messages.
  4. Share the collected information with the support team for further investigation.

     

Recommendation:

We recommend performing the troubleshooting steps through the RA Portal using the Netpulse service and, as an alternative, directly from a computer connected to the customer's local network. Comparing the results will help isolate whether the issue is related to the target device, local network configuration, firewall restrictions, or the remote access path.

Note: If the issue persists, please share the test results and relevant screenshots with the support team for further investigation.