Maintaining robust log rotation and retention for L2TP VPN infrastructure is essential for security, operational stability, and regulatory compliance. L2TP often runs together with IPsec (e.g., L2TP/IPsec using xl2tpd + strongSwan/libreswan) and produces logs across several subsystems: kernel, ipsec daemons, xl2tpd, and systemd/journald or syslog. This article provides a practical, systems-focused guide for implementing a resilient log rotation and retention strategy for L2TP VPN servers, covering typical log locations, rotation mechanics, retention policies, secure transport, integrity controls, and sample configurations you can drop into production.

Understanding where L2TP logs live

Before designing rotation and retention, you must inventory log sources. Common sources for an L2TP/IPsec stack include:

  • xl2tpd logging to /var/log/daemon.log, /var/log/syslog, or to a dedicated file like /var/log/xl2tpd.log depending on syslog config.
  • IPsec daemons (strongSwan, libreswan) often log to /var/log/auth.log, /var/log/secure, or dedicated logs configured in rsyslog or the daemon.
  • Kernel messages and iptables/uids that affect VPN are logged via dmesg or /var/log/kern.log.
  • systemd-journald on modern systems — journald stores binary logs managed separately from text files.
  • Application-level logs if you run management UIs or RADIUS servers for authentication (e.g., FreeRADIUS logs).

Map your syslog configuration

Inspect /etc/rsyslog.conf, /etc/rsyslog.d/* or /etc/syslog-ng/ to confirm where each facility writes. For example, ensure authpriv events (IPsec auths) are routed to /var/log/auth.log and daemon events to /var/log/daemon.log or to dedicated files if you prefer segmentation.

Log rotation basics: logrotate and journald

Two rotation systems are typical: logrotate for text logs and systemd-journald for binary journal logs. Both require configuration tuned to storage and compliance requirements.

logrotate: recommended options and sample config

Key options to consider:

  • rotate N — number of rotated files to keep.
  • daily/weekly/monthly — rotation frequency.
  • compress and delaycompress — compress older logs, but not the most recent rotated file to avoid issues with services reading files.
  • copytruncate vs postrotate restart — use postrotate with service reload when daemons support SIGHUP to reopen log files. Use copytruncate only when restart/hup is not possible (it can lose log entries in the tiny window during copy).
  • notifempty — skip empty logs.
  • Manage permissions and ownership with create.

Sample /etc/logrotate.d/l2tp-vpn for xl2tpd and ipsec logs:


/var/log/xl2tpd.log /var/log/auth.log /var/log/daemon.log {
  daily
  rotate 30
  compress
  delaycompress
  missingok
  notifempty
  create 0640 root adm
  sharedscripts
  postrotate
    # signal rsyslog to reopen files
    /usr/bin/systemctl reload rsyslog.service >/dev/null 2>&1 || true
  endscript
}

This example keeps 30 days of compressed logs and triggers a rsyslog reload to ensure daemons start writing to new files.

Managing systemd journals

journald keeps the logs in binary format under /var/log/journal (if persistent) and is controlled via /etc/systemd/journald.conf. Important settings:

  • SystemMaxUse — the maximum disk space journals may use.
  • SystemKeepFree — space journald should reserve.
  • SystemMaxFileSize and SystemMaxFiles — per-file caps and retention by file count.

To reduce journal disk usage quickly you can run:

  • journalctl --vacuum-size=1G — reduce journals to under 1GB.
  • journalctl --vacuum-time=30d — retain only last 30 days.

Retention policy design for security and compliance

Retention must balance forensic needs, legal/regulatory requirements, and storage costs. Here are practical guidelines to formulate a retention policy:

  • Classify logs by sensitivity: authentication records, configuration changes, connection metadata (source/destination IPs) vs verbose debug logs. Keep sensitive logs longer.
  • Minimum baseline: keep authentication and connection logs for at least 6 months for internal incident response. Many compliance regimes require 1 year or more.
  • Regulatory examples: PCI-DSS may require 1 year of logs with 3 months readily accessible; HIPAA requires audit logs retained per organization policy (often 6 years). GDPR does not specify precise retention periods but expects data minimization and documented retention schedules.
  • Implement tiered retention: keep 90 days of immediately accessible logs on local fast disk, compress and archive older logs to cheaper storage for 1–3 years, and allow deletion after policy expiration.

Retention implementation: local + remote archival

Best practice is to retain current logs locally and ship copies to a remote log server or object storage. Benefits include tamper-evidence and availability if the primary server is compromised.

  • Use rsyslog/graylog/Logstash with TLS forwarding to a centralized log collector.
  • Archive rotated logs to S3-compatible object storage with server-side encryption (SSE) or to an immutable WORM store if compliance demands it.
  • Keep cryptographic hashes (SHA256) of archives for integrity verification; store checksums in a separate system (e.g., a database or key-value store).

Secure transport and tamper-resistance

Sophisticated attackers may try to evade detection by altering logs. Implement these controls:

  • Forward logs in real time to a remote collector over TLS. Example rsyslog forwarding stanza (RSYSLOG v8):


module(load="imtcp")
input(type="imtcp" port="514")
…
action(type="omfwd" Target="logs.example.net" Port="6514" Protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" Template="RSYSLOG_SyslogProtocol23Format")

  • Use client and server certificates, TLS 1.2+ and strong cipher suites.
  • Enable log signing or append-only storage where possible. Solutions like AWS S3 Object Lock or write-once media provide tamper-evidence for archives.
  • Restrict access to log files with UNIX permissions, ACLs, and SELinux contexts; only allow necessary admins to read logs.

Integrity and verification

Routine hash verification of archived logs is a lightweight integrity control. Example cron job flow:

  • After logrotate completes, compress and upload to object storage.
  • Compute sha256sum and store the digest in a signed manifest (GPG or private key signature).
  • Periodically verify manifest signatures and hashes to detect tampering.

Operational tips, automation and alerts

Implement monitoring around logging behavior:

  • Alert when log volumes drop unexpectedly — could indicate logging disabled.
  • Monitor disk utilization for /var/log and journal storage and set early warning thresholds.
  • Schedule regular recovery drills: restore archived logs and run sample forensic queries to ensure archives are usable.

Automate retention enforcement with scripts that integrate logrotate postrotate hooks, archival upload, and manifest signing. Keep the automation minimal and auditable.

Sample end-to-end flow (practical)

1) Configure rsyslog to write daemon, auth logs and xl2tpd to dedicated files.
2) Deploy the logrotate snippet shown earlier; rotate daily and keep 90 days locally. Compress and delaycompress to save space.
3) Postrotate hook archives rotated logs to a secure staging directory and triggers an uploader script to push files to encrypted object storage and to compute/store SHA256 hashes in a signed manifest.
4) Real-time forward critical logs to a centralized SIEM over TLS; this provides immediate visibility and separate retention.
5) Configure journald limits (e.g., 5G SystemMaxUse) and vacuum jobs to enforce maximum consumption.
6) Define retention policy document (who, what, how long) and implement automated deletion policies for archives that exceed the retention period.

Compliance, audits and documentation

Document the retention policy and technical controls. During audits be prepared to provide:

  • Retention policy and justification tied to business or regulatory requirements.
  • Configuration files for logrotate, rsyslog, and journald.
  • Evidence of secure transport (TLS certs) and archives (checksums, signatures).
  • Access control lists and records of log access (who accessed logs and when).

Good documentation and automation reduce audit friction and demonstrate due diligence.

Conclusion: A practical log rotation and retention strategy for L2TP VPN services combines correct identification of log sources, reliable rotation via logrotate (and journald tuning), secure real-time forwarding to a remote collector, archival with integrity checks, and a documented retention policy aligned with compliance needs. Implementing these controls protects forensic evidence, reduces operational risk, and supports regulatory requirements.

Published by Dedicated-IP-VPN