Getting started: your first brokered session with Ixiea

The fastest way to evaluate Ixiea is not a slide deck — it is a brokered session on a real target. This walkthrough takes you from an empty lab to a recorded SSH session in one sitting: deploy the control plane, optionally wire an identity provider, register a Linux host, bind an access policy, connect through the web console and the SSH gateway on port 2222, then validate that recordings and audit events reach your SIEM. Everything here maps directly to the install docs — Helm for a test cluster, Docker Compose for a single management VM.

Assume one Linux host in a lab VPC reachable from the gateway, and either a corporate IdP group or a local admin account for the pilot. Do not boil the ocean on day one: one target, one policy, one session. Expand from there.

Choose your install path

Ixiea runs as a control plane backed by PostgreSQL and a Redis-compatible cache (Valkey). For a quick lab proof, Docker Compose colocates Postgres 16, Valkey 7, and ixiea/server on one host. For anything you expect to grow, use the official Helm chart — it packages the control plane Deployment, gateway workloads, Services, Ingress, RBAC, and a PodDisruptionBudget tuned for three replicas.

• Docker Compose — best for single-host pre-prod and small internal deployments; ports 8443 (UI), 2222 (SSH), 3389 (RDP), 4400 (database proxy).
• Helm on Kubernetes — canonical production path; pin chart version 2.4.x in lab, external Postgres and Redis preferred.
• Minimum sizing — Small tier: 4 vCPU, 8 GB RAM, 40 GB SSD for up to 100 concurrent sessions.

Step 1: Deploy the control plane

Helm path — add the chart repo, create the ixiea namespace, provision secrets, and install:

helm repo add ixiea https://charts.ixiea.com
helm repo update
kubectl create ns ixiea
kubectl -n ixiea create secret generic wg-secret-key \
  --from-literal=secret="$(openssl rand -base64 32)"
helm upgrade --install ixiea ixiea/ixiea \
  --namespace ixiea \
  --version 2.4.1 \
  --values values.yaml

The first install runs a migration Job that applies schema, seeds the internal CA, and prints a bootstrap URL in the Job logs. Verify with kubectl -n ixiea get pods,svc,ingress and wgctl system health against the in-cluster service.

Docker Compose path — create /opt/ixiea/ with docker-compose.yml, .env, tls/, data/, and recordings/ directories. Set WG_DB_URL, WG_REDIS_URL, WG_SECRET_KEY (exactly 32 bytes base64-encoded — openssl rand -base64 32), WG_PUBLIC_URL, and WG_ADMIN_EMAIL. Bring the stack up with docker compose up -d and tail ixiea logs for the bootstrap link.

cd /opt/ixiea
docker compose pull
docker compose up -d
docker compose logs -f ixiea

Confirm the admin console loads over HTTPS on 8443 (Compose) or your ingress hostname (Helm), database migrations complete, and the default organization is reachable. Click the bootstrap URL to set the initial admin password.

Step 2: Identity provider (optional for lab)

Production deployments federate through SAML or OIDC. For a lab pilot, local admin login is sufficient — enable IdP before inviting operators.

Helm values expose identity.oidc with issuer, clientId, and existingSecret for the client secret. Compose deployments can defer IdP until after the first session proof. When you do configure OIDC, set publicUrl or WG_PUBLIC_URL to match the hostname users reach — redirect URI mismatches are the most common first-week failure.

identity:
  oidc:
    enabled: true
    issuer: https://corp.okta.example.com
    clientId: ixiea
    existingSecret: wg-oidc
    clientSecretKey: clientSecret

Step 3: Register a Linux asset

Navigation: Admin console → Assets → Hosts → Create. Select the built-in Linux platform and complete the form:

• Name — consistent pattern such as lab-app-01.
• Address — hostname or management IP of the target; SSH port default 22.
• Account — attach a privileged system account; vault the password or reference an external secret.
• Tags — env:lab and os:linux for policy target selectors.

Run connectivity validation from the admin console. A failed check usually means the gateway subnet is blocked by a security group on the target — allow inbound TCP 22 from the Ixiea host or LoadBalancer fronting port 2222, not from operator laptops.

Ensure the target firewall permits the gateway: ufw allow from <gateway-subnet> to any port 22 proto tcp. The gateway proxies SSH on port 2222; operators never connect directly to port 22 on the target.

Step 4: Create an access policy

Navigation: Admin console → Access Control → Access Policy → Create. Bind your pilot IdP group (or local admin group) to the lab tag:

• Target selector — tag match env:lab AND os:linux.
• Connection methods — web terminal and SSH gateway (port 2222).
• Obligations — record session, four-hour max duration, MFA when IdP is configured.
• Deny rules — optional in lab; enable command filters before production.

Users never receive the raw target password. The gateway injects credentials at handshake time after policy evaluation succeeds.

Step 5: Connect via web console

Open Workbench in the admin console. Authenticate, select the lab asset, choose the authorized account, and launch a web terminal session. Run harmless commands — hostname, uptime, whoami. Confirm a session row appears in Audit → Sessions with your identity, policy version at connect time, and start timestamp.

The web client uses WebSockets — if you front Ixiea with nginx, set proxy-read-timeout to at least 3600 seconds. A 60-second default cuts live sessions mid-command.

Step 6: Connect via SSH gateway

Native SSH clients proxy through the gateway on port 2222. Authenticate to Ixiea first; the gateway handles target handshake.

ssh -p 2222 operator@lab-app-01@wg.example.com

The username format encodes operator identity and target asset. After connect, run the same validation commands and confirm the session ledger shows a second row — or the same session if reconnecting. Both web and native paths share the same policy and recording pipeline.

Step 7: Validate recording and SIEM forwarding

Playback the session recording in Admin console → Audit → Sessions → select session → Recording. For Compose installs, point WG_AUDIT_SINK at a webhook or syslog target to forward audit events to your SIEM:

WG_AUDIT_SINK=syslog://siem.example.com:514
# or webhook URL for Slack, Teams, or a generic HTTP collector

Export one session as JSON and feed it to your SIEM parser test. Confirm fields include operator identity, asset name, policy version, command transcript or recording artifact ID, and session duration.

• Playback the recording or review the command transcript in the audit viewer.
• Verify audit events appear in your SIEM within the expected latency window.
• Document which parallel path still reaches the target without the gateway — that gap is your phase-two scope.

Common pitfalls

• WG_SECRET_KEY is not 32 bytes — regenerate with openssl rand -base64 32; do not trim trailing = padding.
• Target firewall blocks gateway subnet — SSH timeout with no policy denial in logs.
• Bootstrap URL expired — re-run migration Job logs or check WG_ADMIN_EMAIL delivery.
• Recording missing — object storage not configured; sessions still audit but playback fails.
• WebSocket disconnect — ingress idle timeout too low; increase proxy-read-timeout to 3600.
• Permission denied despite correct password — operator not in IdP group referenced by access policy.
• Direct SSH to target still works — close port 22 from operator subnets; only gateway subnet should reach targets.

What to do next

Once the first session is recorded and forwarded, expand deliberately: add IdP federation, enable MFA, register production assets with stricter policies, configure S3-compatible object storage for recordings, and schedule wgctl backup create for Postgres and artifacts. The goal of day one is proof — one target, one policy, one session with evidence. Everything else is iteration.