In this guide, we will explore ways of troubleshooting the A10 load balancer for Cloudmersive Private Cloud. As with any troubleshooting, we will take a systematic approach to identify the root cause of the issue. By checking for the most common issues, we can identify and confirm the root cause.

In this guide, we will cover:

• Confirming Private Cloud server health
• Confirming network connectivity between the A10 load balancer and Cloudmersive Private Cloud, and from other machines and Cloudmersive Private Cloud
• Sending a Test Request from the A10 Appliance to the Cloudmersive Private Cloud server
• Checking for Windows Firewall rules on the Cloudmersive Private Cloud server
• Checking for hardware/virtualized firewall rules impacting traffic flow to the Cloudmersive Private Cloud server

1. Confirming Private Cloud Server Health

First, confirm if the Cloudmersive Private Cloud server(s) are healthy. To do this, navigate to the following web page on the server itself (e.g., via RDP or console on the server):

http://ip-address-of-server/virus/status

Or if using TLS:

https://server-dns-name/virus/status

You should see an HTTP 200 response and in the response XML/JSON see the value Online under Health.

Next, try navigating to the same URL from another machine on the same network that has access to the server. Verify that this is also reachable and shows the same page and response code.

Finally, try navigating to this URL through your A10 load balancer:

https://a10-load-balancer-DNS-name/virus/status

Note: If you have round-robin or another load-balancing algorithm enabled, you may need to refresh multiple times to see the response from each node in the pool. Each node’s status page often includes its own IP address in the response, making it easy to identify which server responded.

2. Configure A10 Load Balancer Health Checks

If you do not see the status page (from the prior step) load through the A10 load balancer, or you receive a timeout, then traffic is not flowing to the Cloudmersive Private Cloud server in question.

A recommended practice is to set up A10 health monitors for each target server. A10 health monitors continuously check the health of each server and only forward traffic to those that respond successfully.

1. Create or Edit a Health Monitor in your A10 configuration that points to /virus/status.
2. Ensure it uses the correct protocol (HTTP or HTTPS) and that it expects a 200 OK response (or a specific substring, if you want to be more specific).
3. Apply this health monitor to your server pool.

Once configured, review the health monitor status in the A10 load balancer interface. Any nodes that are shown as unhealthy have an issue.

• If the nodes show as healthy when you perform a direct test (Section 1), then it implies network traffic is not reaching the Cloudmersive Private Cloud server from the load balancer.
• If the nodes show as unhealthy even with the direct test, then address potential server-side issues on the Cloudmersive Private Cloud server itself (e.g., service not running, server offline, etc.).

3. Confirming Network Connectivity Between the A10 Load Balancer and Cloudmersive Private Cloud

In this section, we will test basic network connectivity from the A10 load balancer to the Cloudmersive Private Cloud server. These tests bypass the Cloudmersive API microservices and simply validate that HTTP or HTTPS traffic can reach IIS on the server.

Try navigating to the following page on the server itself:

http://ip-address-of-server/index.html

Or if using TLS:

https://server-dns-name/index.html

This page is a static file served by IIS at a very low level. Seeing an HTTP 200 means IIS is operational and reachable locally.

Next, try navigating to the same URL from another machine on the same network. Verify reachability and confirm you get the same page and status code.

Finally, test it via the A10 load balancer:

https://a10-load-balancer-DNS-name/index.html

Again, multiple refreshes may be needed to ensure that you hit each node in the pool. The server’s IP address is usually included in the response to help you identify which node responded.

If you do not see any requests from the A10 load balancer in your Cloudmersive Private Cloud server IIS logs, it indicates that traffic is being dropped or misrouted before it reaches the server. Typical causes include:

• Network routing issues
• Hardware firewalls
• Software firewalls

4. Sending a Test Request from the A10 Appliance to the Cloudmersive Private Cloud Server

You can run connectivity tests directly from the A10 device (often referred to as ACOS, or A10 Thunder). The exact commands may vary slightly by A10 OS version, but commonly you will:

1. SSH to the A10 load balancer’s management IP:

   ssh admin@<A10_Management_IP>
   

2. Enter enable mode (if required):

   enable
   

3. Test connectivity commands:

   • Ping the server:

     ping <cloudmersive_server_IP>
     

   • Telnet to test port connectivity:

     telnet <cloudmersive_server_IP> 443
     

   • Traceroute to identify routing hops:

     traceroute <cloudmersive_server_IP>
     

4. Optional: If your A10 appliance supports a bash shell or debug shell, you can run curl to attempt a direct HTTP or HTTPS request:

   # From a debug or shell prompt
   curl -v http://<cloudmersive_server_IP>:80
   # or
   curl -v https://<cloudmersive_server_IP>:443
   

If these commands fail to connect or time out, you have confirmed there is a network routing or firewall issue between the A10 load balancer and the Cloudmersive Private Cloud server.

5. Checking for Windows Firewall Rules on the Cloudmersive Private Cloud Server

On the Cloudmersive Private Cloud server, verify if Windows Firewall is blocking inbound traffic. Run the following command from Administrator PowerShell to list all rules that affect inbound TCP 80/443:

$fwPolicy2 = New-Object -ComObject HNetCfg.FwPolicy2

$fwPolicy2.Rules |
    Where-Object {
        $_.Protocol -eq 6 -and
        $_.LocalPorts -match "\b(80|443)\b" -and
        $_.Enabled -eq $true
    } |
    ForEach-Object {
        $rule = $_
        # Split the LocalPorts by comma
        $ports = $rule.LocalPorts -split ','
        
        foreach ($port in $ports) {
            $portTrim = $port.Trim()
            if ($portTrim -eq '80' -or $portTrim -eq '443') {
                [PSCustomObject]@{
                    Name            = $rule.Name
                    Description     = $rule.Description
                    Enabled         = $rule.Enabled
                    Action          = if ($rule.Action -eq 0) {"Block"} else {"Allow"}
                    Direction       = if ($rule.Direction -eq 1) {"Inbound"} else {"Outbound"}
                    LocalPort       = $portTrim
                    Protocol        = "TCP"
                    LocalAddresses  = $rule.LocalAddresses
                    RemoteAddresses = $rule.RemoteAddresses
                    Profiles        = $rule.Profiles
                }
            }
        }
    } |
    Format-Table -AutoSize

Review any rules shown and adjust them as needed. For example, if a rule blocks inbound port 80 or 443 from your A10 load balancer IP range, allow or remove that blocking rule accordingly.

6. Checking for Hardware/Virtualized Firewall Rules Impacting Traffic Flow

If all tests indicate the Cloudmersive server is healthy, but you cannot reach it through the A10 load balancer, the next step is to look at hardware or virtual firewall rules (e.g., perimeter firewalls, VM security groups, etc.). Work with your networking team to ensure:

• Proper routing is in place between the A10 load balancer and the Cloudmersive Private Cloud servers.
• Firewall rules allow inbound traffic on ports 80 and/or 443 (depending on your setup) from the A10’s self IP or SNAT IP.
• No additional restrictions exist (e.g., geo-blocking or IP whitelisting) that could selectively block some or all A10 traffic.

Sometimes, rules are only partially applied to certain servers, resulting in a subset of servers failing even though the rest are healthy.

Conclusion

Using a systematic approach—verifying server health, confirming network connectivity, setting up health monitors, and reviewing firewall or routing rules—will typically isolate any issues with the A10 load balancer and Cloudmersive Private Cloud integration. By following the steps above, you can efficiently pinpoint whether the issue lies in the application configuration, the network path, the load balancer settings, or the Cloudmersive Private Cloud server configuration itself.