• Clear Browser Cache / Try Incognito:
  The SCG web interface relies heavily on browser caching. After CLI patches, a cached 5.34 layout will completely break when talking to a partial 5.36 backend, resulting in connection drops or blank pages on port 5700.
• Restart the Docker Services:
  Since the full appliance reboot did not help, try forcing Docker to tear down and recreate the container network stack:
   

  systemctl restart docker
  

   

   

  Use code with caution.

   
• Verify Listening Ports on the Host:
  Run ss -tlnp | grep 5700 on the SLES host (not inside the container). If dockerd is listening but curl fails, the issue is usually an internal Docker routing mesh failure or a firewall rules block (iptables) that happened during the dirty upgrade.

Port answer first: 5700 is correct for the dashboard (HTTPS UI). Port 5700 is used to open the secure connect gateway user interface using HTTPS with TLS v1.2, while 9443 is for registering and receiving alert/heartbeat data from storage devices via REST APIs — it's not the dashboard port, so the 404 there is expected/normal. Your real problem is 5700 refusing connections. 

Yes, the alert service is a strong suspect, but check port 162 first. Dell's own troubleshooting guide notes this service needs port 162 free — if something else is using it, the alert service won't start. Run ss -tlnp | grep 162 to check for a conflict (SNMP trap daemon is a common culprit). 

There's also a documented KB (000259425) for this exact FAILED state, where SNMP usage was found to cause incompatibilities that stopped the Alert Service, confirmed via the Alert Service log and Application log showing the SNMP Telegraf process failing to start. The fix there was temporarily disabling SNMPv3 and restarting the Alert Service, which let it reinitialize with the updated settings. Worth checking if SNMPv3 is configured on your gateway. 

On log access: since journalctl is blocked inside the container, skip it — look for the actual SCG application/Alert Service log files directly under the SCG install path (typically under /opt/dell/scg or similar mounted volume, not systemd journal) rather than fighting container permissions.

Bottom line for your next step:

Check for a port 162 conflict
Check if SNMPv3 is enabled — disable temporarily and restart the alert service (wd stop/wd start secureconnectgatewayalertservice)
Confirm actual version via /opt/esrsve/version as you planned — a mismatch there would confirm the CLI upgrade didn't fully apply, which could independently be blocking 5700

@Mark Franklin​ Thank you for response! I tested as suggested and in terms of port 162, there is no conflict. Also for SNMPv3, I cannot determine if this is enabled or not without the web UI. However, I was able to narrow down the problem:

Subject: SCG VE Alert Service FAILED post-upgrade (5.34.00.16 → 5.36.00.16) — confirmed root cause: Telegraf secretstore/keyring error

Environment:

• Secure Connect Gateway Virtual Edition, Hyper-V, SUSE Linux Enterprise Server 15 SP6, Docker-based
• Support ID: 03879033

Summary: Upgraded from 5.34.00.16 to 5.36.00.16 via CLI (SCG-5.36.00.16.bin --upgrade), which reported success. Web dashboard remains inaccessible on both port 5700 and 9443 (5700 refuses connection; 9443 returns "Page Not Found" at root). wd health inside saede-app shows secureconnectgatewayalertservice in a FAILED state, matching the pattern described in KB 000259425.

Root cause — confirmed, not inferred:
Traced the exact command the production systemd unit runs (cat /usr/lib/systemd/system/secureconnectgatewayalertservice.service → ExecStart=.../secureconnectgatewayalertservice start), then followed that wrapper script's own start() function to its actual Telegraf invocation:

${SCG_HOME}/bin/bin/telegraf --config ${SCG_HOME}/bin/conf/alert_processing.conf

Ran this exact command manually to capture the live error (rather than relying on journalctl, which returns "Permission denied" / "No journal files were opened" inside this container regardless of user):

E! retrieving resolver failed: linking secrets failed: resolving "@{secretstore:tlskey}" failed: The specified item could not be found in the keyring

Since this reproduces using the identical command and config path the real service uses, this is confirmed as the actual failure — not an artifact of testing in isolation.

What this means: Telegraf's config references a secret named tlskey that's expected to be resolvable from a secretstore/keyring, and that secret appears to be missing or unreachable following the upgrade.

What's blocked on our end:

• Per Dell's documentation, the SNMPv3-related fix in KB 000259425 requires toggling a setting in the SCG web UI — which is unreachable, creating a catch-22.
• No documented CLI/config method to inspect or repair the secretstore/keyring itself was found in Dell's VE User's Guide or Troubleshooting Guide.
• We have not attempted to manually inject/modify the keyring entry, since this is security-sensitive and undocumented territory we didn't want to touch without guidance.

Ask: Given the confirmed missing tlskey secret, is there a supported way to re-provision/regenerate this key from the CLI or via Dell's backend, given the UI (which would normally be used) is currently inaccessible as a direct consequence of this same failure? Also I wanted to ask if the tlskey secret used by Telegraf's SNMP alert listener is the same certificate that serves the web dashboard, or are these separate keys?

@Dell-Martin S​ Thank you for the input! I've tried rebooting the VM itself with no luck so I didn't try restarting the docker since it would have the same affect.

For  listening ports, I confirmed that dockerd is listening via ss, confirmed curl fails locally exactly as described — and we've already traced this to the container's internal app listening on 7779 while Docker maps 5700-5705, a mismatch that appears to have been introduced or exposed by the upgrade.

1. Find the internal IP address of the container. Run this command on your Hyper-V SUSE host:
   bash

   docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' saede-app
   

    

    
   (Note down the IP, which usually looks like 172.17.0.x or similar).
2. On your local desktop/laptop machine, open a command prompt or terminal and create an SSH tunnel into your SCG host:
   bash

   ssh -L 8443:[CONTAINER_INTERNAL_IP]:7779 root@[YOUR_SCG_HOST_IP]
   

    

    
   (Keep this terminal window open; this creates a secure pipeline).
3. Open your desktop web browser and navigate to:
   text

   https://localhost:8443
   

    

    
   If the core web application layer is alive and well, this tunnel will deliver you straight to the login dashboard, bypassing the 5700/7779 translation error.

@Dell-Martin S​ 

Hello Martin, thank you for the continued help I really appreciate it. So today I tried a bunch of things stemming from your suggestion as summarized below:

Summary for the Dell Community thread:

Issue: SCG dashboard unreachable externally on ports 5700-5705 after upgrading to 5.36.00.16 (Docker & Podman release).

Background: saede-app container's internal watchdog service was found bound to port 7779 instead of the Docker-mapped 5700-5705 range, causing "connection refused" externally.

Steps tried:

1. SSH tunnel workaround (per community suggestion) — hit an SSH host key mismatch warning first. Verified via console that the new key was legitimate (confirmed matching fingerprint), cleared the stale known_hosts entry, reconnected successfully.
2. Tunnel itself failed — SSH server rejected the -L forward with administratively prohibited: open failed (TCP forwarding disabled in sshd_config, likely intentional hardening). Abandoned this path rather than loosen SSH security on an ITAR-scoped host.
3. Tried rebinding the app internally to 5700 instead — traced the listening process to watchdogservice.jar (Spring Boot 3.4.10), found port: 7779 in /opt/esrsve/watchdogservice/watchdogservice_sae.yml, changed it to 5700, restarted container. Result: the service failed to bind on any port after the edit (empty listener). Reverted to backup (port: 7779).
4. Uncovered a separate, real bug in the process —startup logs confirm the watchdog serves plain http-nio-7779 (HTTP), not HTTPS, but the suggested test URL was https://localhost:8443. That protocol mismatch alone would explain failures even with a working tunnel.
5. Current finding, in progress: after restoring the config and restarting, the container's internal namespace now shows something listening across the entire 5700-5705 range (previously only 7779). However, curl to localhost:5700 on the SCG host itself still returns "Connection refused," and docker port saede-app shows the mapping as configured but no docker-proxy process is actually running for port 5700 — meaning Docker's port-publishing layer itself appears broken, independent of the application. Currently testing a full docker stop/docker start cycle to see if it re-establishes the proxy/NAT rules correctly.

I'll keep working on this but its been a rabbit hole so far hahaha appreciate the help as always!