Secure Socket Tunneling Protocol (SSTP) is widely used to provide TLS-protected VPN tunnels — especially where HTTPS traffic is allowed but other VPN protocols might be blocked. For operators and administrators, reliable centralized logging of SSTP events is critical for troubleshooting, audits, and security monitoring. This article walks through a practical, step-by-step approach to collect and analyze SSTP VPN logs using syslog-ng, including how to forward Windows RRAS (or SoftEther) SSTP logs to syslog-ng, how to structure and secure log transport, and how to parse and retain useful fields such as username, client IP, and session states.

Why centralize SSTP logs with syslog-ng?

Centralized logging enables:

  • Correlated analysis across multiple VPN servers (Windows RRAS, SoftEther, etc.).
  • Longer retention and better indexing than local event logs.
  • Real-time monitoring and alerting via SIEM or custom pipelines.
  • Secure, encrypted transport of logs from edge servers to a central collector.

syslog-ng is a robust and flexible log collector with native support for TLS, structured log formats (JSON), filters, parsers, and multiple destinations (files, databases, Elasticsearch, etc.).

Overview of the architecture

A typical architecture for SSTP logging looks like this:

  • SSTP server(s): Windows Server RRAS or SoftEther on which SSTP is enabled.
  • Local forwarder on each SSTP server (recommended): nxlog or Snare for Windows, or built-in syslog on Linux systems running SoftEther.
  • Central syslog-ng collector: receives logs over TLS on UDP/TCP/relp, normalizes, parses, and writes to storage (file/DB/Elasticsearch).
  • Downstream consumers: SIEM, ELK, Grafana, or custom scripts.

Step 1 — Prepare the syslog-ng collector

Install syslog-ng on a Linux host (Debian/Ubuntu/CentOS). Example for Debian/Ubuntu:

sudo apt-get update && sudo apt-get install syslog-ng syslog-ng-core

Essential configuration decisions:

  • Transport protocol: prefer TCP+TLS for reliable and encrypted delivery.
  • Storage format: JSON is recommended because it enables structured queries downstream.
  • Retention and rotation: control disk usage using logrotate or syslog-ng’s file rotation features.

Basic syslog-ng.conf fragments

The following snippets illustrate a secure TCP/TLS listener, a JSON template, and a simple log path to a file. Place these in /etc/syslog-ng/syslog-ng.conf or include files.

Source (TLS TCP)


source s_net_tls { network(port(6514) transport("tls") tls( key-file("/etc/ssl/private/syslog-ng.key") cert-file("/etc/ssl/certs/syslog-ng.crt") ca-dir("/etc/ssl/certs/") peer-verify(required-untrusted)); ); };

JSON template


template t_json { template("{"timestamp":"$(format-date --iso-8601)","host":"$HOST","program":"$PROGRAM","pid":"$PID","level":"$LEVEL","msg":"${MSG//$\n/ }","sdata":"$SDATA"}n"); };

Destination and log path


destination d_vpn { file("/var/log/sstp/sstp.json" template(t_json) create-dirs(yes) perm(0640)); }; log { source(s_net_tls); filter(f_vpn); destination(d_vpn); };

Note: define f_vpn as a filter for program names or content that match your forwarded SSTP logs (examples below).

Step 2 — Forward Windows RRAS SSTP logs to syslog-ng

Windows RRAS writes SSTP-related entries to the Windows Event Log. To forward these to syslog-ng you must run a forwarder such as nxlog (open-source or professional) on each Windows VPN server.

Install and configure nxlog (Windows)

1. Download and install nxlog Community or Enterprise edition on the RRAS host.

2. Configure event log input and TLS output. Example nxlog.conf:


Module im_msvistalog Query

Module pm_transformer Exec if $EventLog == 'System' and ($SourceName == 'RemoteAccess' or $SourceName == 'RasSstp') drop() ;

Module om_ssl OutputType LineBased Server "syslog.example.com" Port 6514 CAFile "C:\nxlog\certs\ca.crt" CertFile "C:\nxlog\certs\client.crt" CertKeyFile "C:\nxlog\certs\client.key"

Path in_events => p_rras => out_syslog_tls

Adjust the Query or event filters to limit to events whose SourceName is RemoteAccess, RAS, or other relevant SSTP components. You can also filter by EventID (e.g., authentication success/failure, disconnects).

Common Windows Event IDs for SSTP/RRAS

  • 20249: SSTP connection established (example — vendor-specific)
  • 20250: SSTP connection terminated
  • 20256 / 6272: Authentication failures / access denied
  • Event IDs will vary by OS version and role — inspect Event Viewer under “Applications and Services Logs → Microsoft → Windows → RemoteAccess”

Step 3 — Parse and enrich logs on syslog-ng

Raw Windows event text is often verbose. Use syslog-ng parsers and regex to extract structured fields:

  • Client IP / remote address
  • Username (or SID)
  • Session start/stop timestamps
  • Error codes and reason phrases

Extracting fields using regex

Example parser for messages with a typical pattern (adjust regex to your logs):


parser p_sstp { regex-parser(pattern("(?Connected|Disconnected).username=(?[^\s,]+).*client=(?\d+\.\d+\.\d+\.\d+)")); };

Then include the parser in the log path so extracted fields appear as syslog-ng macros ($MSG replaced by structured fields like $action, $user, $client_ip in templates).

Step 4 — Secure transport and authentication

  • Use TLS: Generate a CA, sign a collector certificate, and distribute a client certificate to each forwarder. syslog-ng supports mutual TLS (mTLS) by requiring client certs via peer-verify(required-untrusted).
  • Firewall rules: allow only forwarder IPs to TCP/6514 on the collector.
  • Authentication: in addition to mTLS, limit via IP and require syslog messages to include a unique identifier (eg. host_id) in the payload.

Step 5 — Storage, retention and indexing

Decide where to store logs:

  • Flat files (JSON) under /var/log/sstp/ for simplicity.
  • Elasticsearch for fast searching and dashboards (syslog-ng can forward to Elasticsearch or Kafka).
  • Relational DB for compliance reports.

Retention policy example:

  • Hot logs (30 days) in Elasticsearch.
  • Cold logs (1 year) on compressed files with integrity checksums.
  • Archive older than policy to secure long-term storage.

Step 6 — Alerting and monitoring

Set up alert rules on events indicating possible abuse or failures:

  • Repeated authentication failures for the same username or source IP (possible brute-force).
  • High connection churn or frequent disconnects (network issues or client incompatibilities).
  • Unexpected geographic origin changes for an account (correlate with IP geolocation).

Use SIEM or metric systems (Prometheus + Grafana) by deriving metrics from syslog-ng — e.g., count of “Disconnected” events per minute.

Troubleshooting checklist

  • Verify connectivity: use ss -ltnp or tcpdump -i eth0 port 6514 on collector.
  • Check syslog-ng service logs: journalctl -u syslog-ng for TLS handshake problems.
  • Validate nxlog: check its logs for successful TLS handshake and authentication errors.
  • Test with logger or a lightweight client to simulate messages and ensure parsing templates work.
  • Use syslog-ng-ctl stats to confirm received message counts and dropped messages.

Advanced tips

  • Use structured Windows event channels: configure nxlog to export events as CEF/JSON to make parsing easier.
  • Enrich logs with geoip: syslog-ng supports geoip lookups to add country and ASN for client IPs.
  • Rate-limit noisy sources with log { flags(final); filter(...); rate-limit(...); } patterns to avoid floods.
  • Create a dedicated log index per VPN server in Elasticsearch to simplify per-server analysis.

By following these steps you will have a resilient SSTP log collection pipeline: Windows RRAS (or other SSTP-capable servers) forward event logs via secure TLS to a central syslog-ng collector, which normalizes, parses, and stores events in structured formats for alerting and forensic analysis. This approach improves observability, helps you quickly identify authentication and connectivity issues, and scales as you add more VPN endpoints.

For practical examples and downloadable configuration snippets, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.