OpenConnect Monitoring

To monitor OpenConnect, log in the way an AnyConnect-compatible client logs in: establish the TLS session, submit credentials, and confirm the gateway actually grants access. TunnelHQ runs that complete login flow against your server on a schedule, from multiple regions, and alerts within a second when TLS or authentication fails. Works with ocserv and Cisco-compatible gateways. Free for 5 monitors.

Why an HTTPS 200 doesn't mean your SSL VPN works

OpenConnect is the open implementation of the Cisco AnyConnect SSL VPN protocol: a TLS control channel on TCP/443, with a DTLS data channel on UDP/443 for performance. Because the front door looks like ordinary HTTPS, generic uptime tools are worse than useless here. They connect to 443, see a certificate, maybe fetch the portal page, and report "up". That proves the TLS listener answered. Nothing more.

Everything that takes an SSL VPN down for real users happens after that first TLS byte:

• The auth backend (PAM, LDAP, RADIUS) behind ocserv is down, so every login fails while the portal still renders
• The server certificate expired. AnyConnect-compatible clients refuse to proceed, but a naive HTTPS check that skips verification never notices
• Worker processes are wedged while the main listener still accepts TCP connections
• Session or license limits are exhausted, so new logins are rejected
• The DTLS/UDP path is blocked, leaving users "connected" at dial-up speeds over the TCP fallback

How TunnelHQ monitors OpenConnect

1. Add host and credentials

OpenConnect monitors are credential-based. Three fields: host, username, password. No config file needed, because the protocol negotiates everything else in-band.

2. Real TLS + AnyConnect-compatible authentication

Each check performs the full TLS handshake with certificate validation, then walks the AnyConnect-style authentication exchange, submitting your username and password exactly as the openconnect CLI or Cisco Secure Client would. Only a gateway that accepts the credentials and moves the session forward counts as "up".

3. Distinguish TLS failures from auth failures

When a check fails, the result says which layer broke. An expired certificate, a TLS policy problem, and a rejected login are three different pager messages, and knowing which one fired usually cuts the diagnosis to minutes.

4. Regional checks, sub-second alerts

Checks run from US, EU, APAC, and SA nodes. Regional divergence, failing from one continent and passing from the rest, points at path-level blocking rather than a dead gateway. Alerts fire within a second via email, Slack, Telegram, Discord, and webhooks.

Use a dedicated monitoring account

Because every check is a real login, create a separate account for monitoring:

• Rotate its password without touching real users, and revoke it instantly if needed
• Keep monitoring logins visually distinct in occtl output and gateway logs
• Exempt it from any mandatory 2FA policy. Automated checks can't answer TOTP prompts
• If you cap concurrent sessions per user, give the monitoring account headroom so back-to-back regional checks don't trip the limit

Credentials are encrypted with AES-256-GCM at rest and used for nothing but the check.

Common OpenConnect failure modes TunnelHQ catches

• Certificate expiry or a renewal that deployed the wrong chain
• RADIUS/LDAP outage. The portal renders, logins fail
• ocserv restarted with a broken config and dropped its auth section
• Max-clients or per-user session limits reached, rejecting new logins
• TLS hardening that accidentally cut off older client stacks
• Regional blocking of the gateway's IP or SNI

Automate checks with the REST API

curl -X POST https://tunnelhq.com/api/v1/check/public \
  -H "Content-Type: application/json" \
  -d '{
    "protocol": "openconnect",
    "host": "gateway.example.com",
    "username": "monitor",
    "password": "S3parate-Mon-Acct"
  }'

Want to try one right now? The free protocol tester runs a one-off OpenConnect check. Click the OpenConnect chip, enter host and credentials, done.

Pricing for OpenConnect monitoring

OpenConnect is one of the 11 protocols TunnelHQ monitors. Included in every plan.

See full plan comparison →

OpenConnect monitoring FAQ

Does this work with Cisco gateways, or only ocserv?

Both. The check speaks the AnyConnect-compatible authentication flow, so ocserv and Cisco AnyConnect-compatible SSL VPN gateways that accept username/password logins can be monitored the same way.

What if my gateway requires 2FA or client certificates for everyone?

Automated checks authenticate with username and password, so create a monitoring-only account that's exempt from interactive 2FA. Certificate-only gateways can't currently be monitored with a credential check. Contact us if that's your setup.

Does TunnelHQ verify the DTLS data channel too?

The check validates the TLS control channel and authentication, which is where the overwhelming majority of outages live. Full DTLS data-path verification is on the roadmap. Regional check divergence already surfaces most UDP-blocking events.

We run IKEv2 for native OS clients alongside OpenConnect. Monitor both?

Yes, and you should. They fail independently. See the IKEv2 monitoring guide. If you're also keeping a legacy OpenVPN fleet alive, that's a third independent check under the same dashboard.