Operating and auditing L2TP VPN services requires reliable, structured logging. For administrators, developers, and site operators, the ability to collect, normalize, and analyze L2TP connection records is essential for security, troubleshooting, and compliance. This article walks through a practical syslog‑ng based approach to capture detailed L2TP/PPP events, enrich them for audit purposes, and forward them to long‑term storage or SIEMs.

Why syslog‑ng for L2TP auditing?

Syslog‑ng is a mature, flexible log collector with powerful parsing, templating, and transport features. Compared with simpler syslog implementations, syslog‑ng can:

  • Ingest logs from multiple sources (local files, systemd journal, TCP/UDP, TLS, etc.).
  • Parse and normalize messages using regex, csv-parser, and json-parser.
  • Enrich logs with metadata (host, program, PID, timestamps, correlation IDs).
  • Deliver logs reliably to local storage, remote servers, or cloud SIEMs using TLS/TCP.

These capabilities make it ideal for collecting L2TP and related PPP logs that might be emitted by xl2tpd, pppd, strongSwan (when combined with L2TP/IPsec), or network devices acting as concentrators.

Understanding the log sources: what to capture

Before writing configs, identify the producers of VPN events:

  • xl2tpd — L2TP daemon. Typical messages: session establish/disconnect, peer IP, tunnel ID.
  • pppd — PPP layer used by many L2TP setups: authentication success/failure (PAP/CHAP), IP assignment, link up/down, IPCP negotiations.
  • IPsec daemons (e.g., strongswan, racoon) — if L2TP is secured with IPsec; useful for cryptographic event correlation.
  • Kernel/network logs (iptables, nftables) — packets accepted/dropped for VPN interfaces (pppX, l2tpX).

Collecting all of the above enables correlation: you can map an authentication event (pppd) to an IP assignment and to an IPsec tunnel event.

Typical log lines to watch

  • pppd: “Login succeeded for ‘username’.” or “CHAP authentication succeeded”
  • pppd: “PAP authentication failed”
  • pppd: “local IP address x.x.x.x, remote y.y.y.y”
  • xl2tpd: “L2TP session 123456 established, peer 203.0.113.10”
  • kernel/iptables: “IN=eth0 OUT=ppp0 SRC=203.0.113.10 DST=10.8.0.1” (shows traffic path)

syslog‑ng architecture: source → parse → filter → destination

Designing an auditable pipeline follows the standard syslog‑ng flow. Below are recommended building blocks with concrete examples.

Source: collect systemd journal and /var/log/messages

Systemd-based systems may write to the journal; use the journal source for completeness. Also collect legacy /var/log files if present.

Example sources:

<!-- syslog-ng.conf snippet -->
source s_journal {
    systemd-journal();
};

source s_file {
    file("/var/log/messages" follow_freq(1) flags(no-parse));
};

The flags(no-parse) ensures you get the original message payload for regex parsing later.

Parser: extract fields from pppd/xl2tpd

Use the rewrite and parser primitives to transform text into structured data. Below is a practical pattern that extracts username, auth result, assigned IP, and session IDs from common pppd/xl2tpd messages.

<!-- extract pppd auth/success/failure -->
parser p_pppd_auth {
    # extract "username", "result" and optionally "local_ip" and "remote_ip"
    csv-parser(columns("time","host","program","pid","message")
               delimiters(" ")
               flags(escape-none));
};

rewrite r_extract_pppd {
    subst(replacement("$(extract-pppd-username)"),
          value("$(message)"),
          pattern(".Login succeeded for '([^']+)'."),
          flags(global, caseless));
    # Alternatively use regex parsing for more fields
};

For more precise extraction, use patterndb (pattern database) which lets you define named patterns and produce structured JSON-like events with mapping for audit fields.

Filters: separate audit vs. debug logs

Create filters so audit logs are stored in a dedicated place and have stricter retention. Examples:

filter f_vpn_auth { program("pppd") and match("authentication"); };
filter f_l2tp { program("xl2tpd"); }

Then route these to specific destinations. Keeping auth events separate simplifies compliance exports.

Destination: structured audit files and remote SIEM

For audits, prefer JSON with explicit fields and ISO8601 timestamps. Syslog‑ng templates support this:

template t_audit_json {
    template("{" ""@timestamp":"${ISODATE}","
             ""host":"${HOST}","
             ""program":"${PROGRAM}","
             ""pid":${PID},"
             ""message":"${MSG}","
             ""vpn_user":"${CUSTOM_USER}","
             ""vpn_peer":"${CUSTOM_PEER}","
             ""ppp_local_ip":"${CUSTOM_LOCAL_IP}""
             "}n");
    template_escape(no);
};

destination d_vpn_audit_file {
    file("/var/log/vpn-audit.log" template(t_audit_json) perm(0600));
};

destination d_remote_siem {
    tcp("siem.example.net" port(6514)
        tls(peer-verify(optional-untrusted))
        template(t_audit_json));
}

log { source(s_journal); parser(p_pppd_auth); rewrite(r_extract_pppd); filter(f_vpn_auth); destination(d_vpn_audit_file); destination(d_remote_siem); };

Replace ${CUSTOM_*} variables by setting message metadata during parsing or rewrite steps. You can also use the record transformer (rewrite set-uuid()) to add correlation IDs.

Advanced parsing: patternDB and JSON transformation

PatternDB is particularly effective for VPN logs because it supports multi-line patterns, named macros, and automatic field extraction. Build a patternDB file (XML) with entries for common pppd/xl2tpd messages and load it into syslog‑ng. This produces JSON macros like $!vpn_user you can include in output templates.

Benefits of patternDB:

  • Less brittle than ad‑hoc regex.
  • Reusable across servers.
  • Enables consistent field names for downstream analytics.

Correlating with firewall and IPsec logs

To build a complete audit trail, correlate L2TP session events with firewall accept/drop logs and IPsec events. Tactics:

  • Tag logs with interface names (pppX) — syslog-ng can add interface context by matching message content or by processing kernel logs that include IN/OUT fields.
  • Forward firewall logs to the same SIEM and rely on timestamps and NAT translations to join events.
  • Capture IPsec phase1/phase2 success/failure from strongSwan and link them via peer IP addresses.

Retention, rotation, and compliance

Audit logs are sensitive. Apply the following operational practices:

  • Store audit logs in a write‑once style location wherever possible. At minimum, set file permissions to 0600 and limited ownership (e.g., root:adm).
  • Use log rotation with retention policies that satisfy your compliance (e.g., 1 year for security audits). Example logrotate entry:
/var/log/vpn-audit.log {
    daily
    rotate 365
    compress
    missingok
    notifempty
    create 0600 root adm
    postrotate
        /usr/bin/systemctl reload syslog-ng >/dev/null 2>&1 || true
    endscript
}
  • For long retention and tamper resistance, forward logs to a remote, write‑only storage or cloud SIEM via TLS. Keep local copies only for short term.

Alerting and automated detection

Once logs are structured, set meaningful alerts:

  • Multiple failed authentications for the same username or source IP within a short period → brute‑force alert.
  • Unexpected logins during off hours or from unusual geolocations → risk alert.
  • Session establishment without matching IPsec negotiation logs → possible misconfiguration or bypass.

These alerts can be implemented in the SIEM or by local tools such as fail2ban (watching syslog-ng outputs) or a small ELK/Kibana stack.

Troubleshooting tips

  • If expected messages are missing: verify that the producing process logs to syslog (some daemons log directly to /var/log/daemon.log or to systemd journal). Check journal entries with journalctl -u xl2tpd.
  • Confirm syslog-ng has permission to read log files and the systemd journal. On SELinux systems, ensure appropriate SELinux booleans (setsebool -P) or file contexts.
  • Use temporary debug templates to print raw messages to a local file to inspect patterns before writing parsers.
  • Beware of log flooding: set rate limits in syslog-ng or in the kernel to prevent disk exhaustion from noisy processes.

Security considerations

Audit logs contain usernames, peer IPs, and sometimes cleartext messages. Protect them:

  • Use TLS/TCP for remote forwarding and validate certificates.
  • Restrict access to logs with file system ACLs and monitor changes to log files themselves (integrity monitoring).
  • Mask or redact sensitive fields if necessary before sending to third‑party services (syslog‑ng rewrite rules can redact tokens and passwords).

Example end‑to‑end flow

Putting it all together:

  • Collect systemd journal and /var/log/messages with syslog‑ng sources.
  • Apply patternDB/parsers to extract username, auth result, ppp local/remote IP, session IDs, peer IP.
  • Enrich events with ISO8601 timestamps and correlation IDs.
  • Route authentication and session events to a dedicated audit file and forward the same events to a remote SIEM over TLS/TCP.
  • Configure logrotate and remote retention to meet policy.
  • Create SIEM alerts for failed auths, suspicious geos, and unexpected session behavior.

Monitoring L2TP VPNs with syslog‑ng gives visibility and control over authentication, session lifecycles, and network activity. With careful parsing, secure forwarding, and structured outputs you can meet audit requirements and enable rapid incident response.

For further resources, configuration examples, and managed VPN services with dedicated IPs, visit Dedicated‑IP‑VPN.