# OpenConnect monitoring

To monitor an OpenConnect server, log in the way an AnyConnect-compatible client does: establish the TLS session, submit credentials, and confirm the gateway grants access. TunnelHQ runs that full login from outside, against ocserv and Cisco-compatible gateways, every 1 to 5 minutes by plan, and alerts you in 20 channels when it fails.

[Start Free Trial](https://app.tunnelhq.com/register) [View the API docs](https://docs.tunnelhq.com/api/)

## 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 tunnels 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\. Checks by country, alerts the moment a server is confirmed down

Checks run from the general pool, or from the countries you pin a tunnel to (Pro and Business). Failing from one country and passing from the rest points at path-level blocking rather than a dead gateway. Once a failure is confirmed, alerts go out at once 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://app.tunnelhq.com/api/v1/check/public \
  -H "Content-Type: application/json" \
  -d '{
    "protocol": "openconnect",
    "host": "vpn.yourdomain.com",
    "username": "monitor",
    "password": "S3parate-Mon-Acct"
  }'
```

Want to try one right now? The [free protocol tester](https://tunnelhq.com/test/) runs a one-off OpenConnect check. Click the OpenConnect chip, enter host and credentials, done.

## What a failed check tells you

A failed check comes with a message that says where to look. On an OpenConnect tunnel the most common is Tunnel unreachable. Rejected configurations and Tunnel established - Internet is stuck are rare.

-   **Tunnel unreachable.** The login or tunnel didn't complete. Check that the server is running, that the host (and port, if you set one) are right, and that the username and password work in an AnyConnect or OpenConnect client.
-   **Couldn't complete this check — the monitor's configuration or credentials were rejected. The server's status is unknown.** The tunnel's settings couldn't be used, so there is no verdict on the server. The tunnel shows Unknown, with no alert. Check the host and credentials against a client that connects.
-   **Server reachable — it rejected the monitor's credentials or certificate.** The server answered and refused them. The tunnel reads Degraded with no alert, unless it passed a check in the last 30 days: then TunnelHQ treats the refusal as an outage, and the tunnel goes Down after its retries and alerts.
-   **Tunnel established - Internet is stuck.** The tunnel came up, but traffic didn't reach the internet. Check the server's routing and DNS.

## Need this on a schedule?

A one-off login proves the gateway works this minute. TunnelHQ repeats the full TLS + authentication flow every 1 to 5 minutes by plan against every gateway you run, and fires Slack, email, Telegram, Discord, or webhook alerts as soon as a rejected login is confirmed. Usually before the first support ticket.

## Pricing for OpenConnect monitoring

All plans include OpenConnect monitoring.

| Plan | Tunnels | Check interval | Price |
| --- | --- | --- | --- |
| Free trial | 14 days free on every plan. Your card is charged on day 15, and you can cancel any time before. |
| Starter | 20 | 5 min | $12/mo or $84/yr |
| Pro | 100 | 2 min | $39/mo or $276/yr |
| Business | 500 | 1 min | $99/mo or $756/yr |

[See the full plan comparison](https://tunnelhq.com/pricing/)

[Start Free Trial](https://app.tunnelhq.com/register) [Test a config free](https://tunnelhq.com/test/)

## Read more

-   [OpenConnect in the docs](https://docs.tunnelhq.com/protocols/openconnect/)
-   [IKEv2 monitoring](https://tunnelhq.com/ikev2-monitoring/)
-   [OpenVPN monitoring](https://tunnelhq.com/openvpn-monitoring/)

## OpenConnect monitoring questions

### 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](https://tunnelhq.com/ikev2-monitoring/). If you're also keeping a legacy [OpenVPN](https://tunnelhq.com/openvpn-monitoring/) fleet alive, that's a third independent check under the same dashboard.

Source: https://tunnelhq.com/openconnect-monitoring/