Office VPN Logging: Track Connections and Detect Unauthorized Clients

What “good VPN logging” actually looks like

“Turn on VPN logs” is not a plan. It’s a sentence people say when they want the feeling of security without the work.
Good VPN logging is a system: it records enough context to answer the questions you’ll be asked, quickly, under pressure, without requiring heroics.

The questions you must be able to answer

• Who connected? Not just a username—an identity chain: user, auth method, certificate/PSK identity, and where possible, device identity.
• From where? Public source IP, ASN/geo if you do that internally, and whether it’s a known corporate egress.
• With what? Client version, OS hints, cert fingerprint, and for WireGuard: peer public key.
• When? Connection start/stop, rekey times, roaming events, and session duration.
• What did it touch? At minimum: assigned VPN IP, routes pushed, and key subnet access attempts via firewall/VPN gateway logs.
• Was it allowed? Auth success/failure and the policy decision point (RADIUS, LDAP, SAML/OIDC gateway, local cert validation, etc.).
• How confident are we? Can we distinguish “this user on their laptop” from “someone holding a copied config file”?

What you should avoid

Avoid logs that are high-volume but low-truth. Packet captures as your primary audit trail. Random debug dumps enabled for months.
Unstructured text without consistent fields. Anything that turns incident response into folklore.

You don’t need to log every packet. You do need to log every session, every authentication decision, and every meaningful policy boundary crossing.
The trick is that “meaningful” depends on your office reality: Finance shares matter; the printer VLAN… less so, unless you’ve met printers.

Joke #1: The only thing more persistent than a leaked VPN credential is the email thread arguing whether the VPN logs are “too noisy.”

Facts & historical context that explain today’s mess

VPN logging feels like a modern headache, but it’s been evolving for decades—often in response to security failures and operational pain.
A few concrete facts help explain why offices end up with blind spots.

1. PPP and RADIUS accounting predate most “modern VPNs”. The notion of “user connected for X minutes, assigned IP Y” existed in dial-up days and still matters.
2. IPsec was designed for network-to-network tunnels first. Remote access became a dominant use later, which is why identity mapping can feel bolted on.
3. OpenVPN popularized “TLS + certificates” for remote access on commodity systems. Great for security; terrible for attribution if you reuse certs.
4. WireGuard intentionally exposes less metadata. It’s lean and fast, but “user logged in” is not a native concept; you must build identity mapping around keys.
5. NAT and CGNAT broke naive “source IP equals person” thinking. Many clients can share one public IP, and one person can roam across many IPs in a day.
6. Split tunneling changed the game for forensics. Not all traffic passes the VPN, so “they were connected” doesn’t mean “they did it through the tunnel.”
7. TLS 1.3 reduced handshake visibility for middleboxes. You get better privacy/security, but less incidental metadata to lean on.
8. Log retention became a compliance topic, not just ops. Many orgs keep VPN logs because audits demand it—not because they’re good at using them.
9. Cloud identity providers shifted “authentication” away from the VPN box. If your VPN terminator isn’t the decision maker, your logs must join across systems.

These aren’t trivia. They explain why “just check the VPN logs” often leads to a dead end unless you designed the logging pipeline deliberately.

A sane logging model: identity, device, session, and traffic signals

1) Identity: the human (or service) behind the tunnel

Identity must be anchored in an authoritative source: your IdP, directory, or HR-driven identity lifecycle. The VPN should log:
username (or subject DN), auth method, and the policy outcome.

If you use certificates, log the certificate fingerprint and serial number, not just CN. CNs are people’s favorite lie.
If you use SAML/OIDC in a gateway, capture the assertion subject and session ID and forward it to the VPN gateway logs.

2) Device: what’s connecting

“Device identity” can be:

• WireGuard public key (strong, if managed well)
• Client certificate fingerprint (strong, if unique per device)
• MDM device ID forwarded by the gateway (strongest, if you have MDM)
• Client-reported hostname/OS (weak, but sometimes helpful)

In an office environment, unique per-device credentials are non-negotiable. Shared VPN profiles are a factory for untraceable mess.

3) Session: the lifecycle of a connection

A VPN session is your unit of truth. For each session, log:
start time, end time, assigned VPN IP, peer IP:port, bytes in/out, and rekey or reconnect events.

If your VPN doesn’t provide “end time” cleanly (hello, abrupt Wi‑Fi roams), approximate it via inactivity timeouts and log those timeouts explicitly.

4) Traffic signals: policy boundaries, not payload

You don’t need payload. You do need evidence of access.
The clean approach is: VPN session logs + firewall logs at subnet boundaries + critical service logs (file server, RDP gateway, Git, ERP).

One quote worth keeping near your runbooks: Hope is not a strategy. — Gene Kranz.

Instrumentation by VPN type (OpenVPN, WireGuard, IPsec/StrongSwan)

OpenVPN (classic office workhorse)

OpenVPN gives you rich connection logs, but you must configure them with intent. The defaults tend to be chatty in the wrong ways and silent in the right ones.
Priorities:

• Log to a file with predictable rotation (or syslog) and include connection, auth, and IP assignment events.
• Enable the management interface if you need live session visibility (but protect it).
• Use per-client configs and unique certs; log certificate fingerprints.
• Push a stable “ifconfig-pool-persist” mapping so VPN IP addresses aren’t random every day.

WireGuard (minimalist by design)

WireGuard logs are intentionally sparse. It’s not a failure; it’s a design choice. The “identity” is the public key.
Your job is to map key → user/device, track handshake times, and alert on new/unknown keys.

WireGuard won’t tell you “user authenticated.” Your authorization is the presence of a peer key in configuration, plus whatever you use to manage key distribution.
That means: your change management and key inventory are part of your security model, whether you like it or not.

IPsec/StrongSwan (enterprise-ish, still everywhere)

StrongSwan can produce good logs, especially around IKE negotiation, EAP identity, certificate validation, and child SA lifetimes.
Common operational reality: the identity decision might happen in RADIUS (EAP) or certificates, while the “what subnet did they reach” is somewhere else.
You need to stitch.

Centralize, normalize, correlate: stop reading logs like a novel

Centralize

If VPN logs live only on the VPN box, you’ll lose them when you need them most: during an outage, a disk-full incident, or a compromised host.
Ship logs off-host in near real-time. Use TLS for transport. Keep local logs too, but treat them as a cache, not the source of truth.

Normalize

Free-text logs are fine for humans, bad for detection. Parse into fields:
timestamp, vpn_type, server, username, device_id (cert fingerprint or WG key), src_ip, vpn_ip, bytes_in, bytes_out, auth_result, reason.
If you’re lucky, your SIEM already has parsers. If not, make them. It pays back every incident.

Correlate

Correlation is not “throw everything into Elasticsearch and hope.” Correlation is deliberate joins:

• VPN session ↔ authentication decision (RADIUS/IdP logs)
• VPN session ↔ firewall accepts/denies from VPN subnet
• VPN session ↔ critical service access (SMB, SSH, RDP, web apps)
• User lifecycle events ↔ VPN account validity

The operational goal: one search that answers “what did this user/device do over VPN between 01:00–03:00?”
Not five dashboards and a Slack argument.

Practical tasks (commands, outputs, and decisions) — 12+ you can run today

The fastest way to improve VPN logging is to touch the system. Below are concrete tasks with commands, typical outputs, what the output means,
and the decision you should make.

Task 1: Confirm which VPN service is actually running (systemd)

cr0x@server:~$ systemctl list-units --type=service | egrep 'openvpn|wg-quick|strongswan|ipsec' | cat
openvpn-server@office.service loaded active running OpenVPN service for office
strongswan.service             loaded inactive dead    strongSwan IPsec IKEv1/IKEv2 daemon

What it means: OpenVPN is active; StrongSwan is installed but not running.

Decision: Focus logging work on OpenVPN. If you intended to run IPsec, you have a drift problem—fix your service ownership and deployment.

Task 2: Check where OpenVPN logs go and at what verbosity

cr0x@server:~$ sudo egrep -n '^(log|log-append|status|verb|management|ifconfig-pool-persist)' /etc/openvpn/server/office.conf
7:log-append /var/log/openvpn/office.log
9:status /run/openvpn/office.status 10
12:verb 3
18:ifconfig-pool-persist /var/lib/openvpn/ipp.txt

What it means: Logs are appended to a file; status is updated every 10 seconds; verbosity is moderate; IP assignments persist.

Decision: Keep verb 3 for production unless troubleshooting. Confirm office.log is rotated and shipped off-host.

Task 3: Verify log rotation (avoid “disk full” as a security control)

cr0x@server:~$ sudo cat /etc/logrotate.d/openvpn
/var/log/openvpn/*.log {
  weekly
  rotate 12
  missingok
  notifempty
  compress
  delaycompress
  copytruncate
}

What it means: Weekly rotation, 12 weeks retention, compression, and copytruncate so OpenVPN keeps writing.

Decision: For incident response, 12 weeks might be too short. Adjust to your policy (often 90–180 days). Ensure off-host retention is longer.

Task 4: Tail live connections and look for identity markers

cr0x@server:~$ sudo tail -n 8 /var/log/openvpn/office.log
2025-12-28 10:11:12 us=510332 alice/198.51.100.23:53422 VERIFY OK: depth=1, CN=OfficeVPN-CA
2025-12-28 10:11:12 us=526119 alice/198.51.100.23:53422 VERIFY OK: depth=0, CN=alice-laptop
2025-12-28 10:11:12 us=710402 alice/198.51.100.23:53422 Peer Connection Initiated with [AF_INET]198.51.100.23:53422
2025-12-28 10:11:13 us=10405 alice/198.51.100.23:53422 MULTI_sva: pool returned IPv4=10.8.0.42, IPv6=(Not enabled)
2025-12-28 10:11:13 us=20211 alice/198.51.100.23:53422 Initialization Sequence Completed

What it means: You have username + source IP:port + client cert CN + assigned VPN IP.

Decision: Ensure the cert CN is unique per device. If you see generic CNs like client, you’re already in attribution debt.

Task 5: Use the OpenVPN status file for current sessions (low friction)

cr0x@server:~$ sudo head -n 20 /run/openvpn/office.status
OpenVPN CLIENT LIST
Updated,2025-12-28 10:11:20
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
alice-laptop,198.51.100.23:53422,1184021,992210,2025-12-28 10:11:12
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.42,alice-laptop,198.51.100.23:53422,2025-12-28 10:11:20
GLOBAL STATS
Max bcast/mcast queue length,0
END

What it means: A quick authoritative view of active clients and their VPN IP mapping.

Decision: Use this for on-call triage and to cross-check SIEM parsing. Alert if a “Common Name” appears that isn’t in your inventory.

Task 6: Detect duplicate certificate usage (same CN from different IPs)

cr0x@server:~$ sudo awk -F, 'NR>3 && $1!="ROUTING TABLE" && $1!="GLOBAL STATS" && $1!="END" {print $1}' /run/openvpn/office.status | sort | uniq -c | sort -nr | head
1 alice-laptop

What it means: Right now there’s only one session per cert CN.

Decision: If you see counts > 1, you may have shared certs, duplicated profiles, or credential theft. Investigate immediately and rotate credentials.

Task 7: WireGuard peers—who has configured access, and who recently handshook

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 9V6rQ6n8Qv5sYcR0mQJm8h1m0cWkYq2yP0bQ2xkJ1wE=
  listening port: 51820

peer: n4bR9nQyQXW4x9m3q6m0Zf9d0uE4Kxjzv8kq3p7p8fY=
  preshared key: (hidden)
  endpoint: 203.0.113.17:45678
  allowed ips: 10.9.0.10/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 88.24 MiB received, 19.10 MiB sent

What it means: A specific peer key is active recently, from a public endpoint, with a fixed VPN IP.

Decision: If a peer has latest handshake but no matching owner in your key inventory, treat it as unauthorized until proven otherwise.

Task 8: StrongSwan / IPsec log visibility (journald)

cr0x@server:~$ sudo journalctl -u strongswan --since "1 hour ago" | tail -n 8
Dec 28 09:38:20 vpn-gw charon[1120]: 10[IKE] received EAP identity 'bob'
Dec 28 09:38:20 vpn-gw charon[1120]: 10[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established
Dec 28 09:38:21 vpn-gw charon[1120]: 10[IKE] authentication of 'vpn-gw' (myself) with RSA signature successful
Dec 28 09:38:21 vpn-gw charon[1120]: 10[IKE] IKE_SA office[7] established between 192.0.2.10[vpn-gw]...198.51.100.88[bob]

What it means: You have an EAP identity and the remote public IP tied to SA establishment.

Decision: If EAP identities are missing or inconsistent, fix your EAP/RADIUS integration. Identity-less IPsec is a compliance argument waiting to happen.

Task 9: Confirm off-host log shipping is working (rsyslog example)

cr0x@server:~$ sudo grep -R "omfwd" -n /etc/rsyslog.d | head
/etc/rsyslog.d/50-vpn.conf:3:*.* action(type="omfwd" target="loghub01" port="6514" protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="loghub01")

What it means: Logs are forwarded to a central host over TLS.

Decision: Validate delivery on the log hub. If you can’t prove logs arrive, assume they don’t when it counts.

Task 10: Identify noisy auth failures (spray or misconfiguration)

cr0x@server:~$ sudo egrep -h "AUTH_FAILED|TLS Auth Error|AUTH: Received control message" /var/log/openvpn/office.log | tail -n 5
2025-12-28 09:55:01 us=100212 TLS Auth Error: TLS handshake failed
2025-12-28 09:55:02 us=220118 TLS Auth Error: TLS handshake failed
2025-12-28 09:55:05 us=992118 AUTH: Received control message: AUTH_FAILED
2025-12-28 09:55:06 us=110111 AUTH: Received control message: AUTH_FAILED

What it means: There are handshake failures and explicit auth failures—could be password spray, a broken client, or someone probing.

Decision: Correlate with source IPs. If concentrated from a few IPs, block/rate-limit and investigate. If spread, look at credential stuffing detection and MFA enforcement.

Task 11: Find “new country/new ASN” type anomalies (quick-and-dirty)

cr0x@server:~$ sudo awk '/Peer Connection Initiated/ {print $3}' /var/log/openvpn/office.log | tail -n 5
[AF_INET]198.51.100.23:53422
[AF_INET]203.0.113.55:61210
[AF_INET]198.51.100.201:49990
[AF_INET]203.0.113.77:54001
[AF_INET]192.0.2.44:53111

What it means: The list of recent public endpoints. This is raw; you’ll enrich it in your SIEM with geo/ASN.

Decision: If you see unexpected ranges (e.g., data center IPs for employees), escalate. If you can’t enrich, you’re flying without instruments.

Task 12: Validate VPN IP allocations are stable (helps correlation)

cr0x@server:~$ sudo tail -n 5 /var/lib/openvpn/ipp.txt
alice-laptop,10.8.0.42
bob-phone,10.8.0.43
svc-backup,10.8.0.200

What it means: Common Name maps to stable VPN IPs.

Decision: Keep it stable for humans and log correlation. Reserve ranges for service accounts and label them aggressively.

Task 13: Tie VPN sessions to firewall events (nftables example)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,40p'
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iifname "tun0" ip saddr 10.8.0.0/24 ip daddr 10.10.0.0/16 tcp dport { 22, 3389, 445 } log prefix "VPN-FWD " accept
    log prefix "DROP-FWD " drop
  }
}

What it means: You log accepted forwards from VPN to internal subnets for sensitive ports.

Decision: Keep logs at boundaries. If you accept without logging for critical ports, you’ll regret it during an investigation.

Task 14: Spot a rogue client by VPN IP hitting forbidden subnets (log grep)

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep "VPN-FWD|DROP-FWD" | tail -n 6
Dec 28 09:41:02 vpn-gw kernel: VPN-FWD IN=tun0 OUT=eth0 SRC=10.8.0.42 DST=10.10.12.5 LEN=60 PROTO=TCP SPT=51122 DPT=445
Dec 28 09:41:03 vpn-gw kernel: DROP-FWD IN=tun0 OUT=eth0 SRC=10.8.0.42 DST=10.20.50.10 LEN=60 PROTO=TCP SPT=51122 DPT=3306

What it means: VPN IP 10.8.0.42 accessed SMB on allowed subnet, then tried MySQL on a denied subnet.

Decision: Investigate whether that user should ever touch database networks. Repeated DROP patterns are a strong indicator of scanning or misconfigured apps.

Task 15: Confirm time sync (because timestamps are the spine of forensics)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 10:12:40 UTC
           Universal time: Sun 2025-12-28 10:12:40 UTC
                 RTC time: Sun 2025-12-28 10:12:40
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

What it means: Clock is synchronized. Your cross-system correlation won’t be off by 7 minutes like it’s 2009.

Decision: Enforce NTP everywhere (VPN gateways, RADIUS, IdP proxies, log hubs). If time is wrong, your logs are fan fiction.

Fast diagnosis playbook: what to check first/second/third

When “VPN is weird” hits, you need a short sequence that finds the bottleneck fast. This is that sequence.
The key is to separate auth, tunnel, routing, and application problems in minutes.

First: Are clients authenticating or just failing to handshake?

• Check recent AUTH_FAILED and TLS/IKE negotiation errors.
• Compare counts to baseline. Bursts suggest password spray or a broken client rollout.
• If using RADIUS/IdP: check whether the auth backend is healthy and reachable.

Second: Are tunnels established and stable?

• OpenVPN: status file shows “Connected Since” and bytes moving.
• WireGuard: latest handshake and increasing transfer counters.
• IPsec: IKE_SA and CHILD_SA established; look for frequent rekeys or deletes.

Third: Is routing/policy correct for VPN subnets?

• Verify the VPN subnet is routed to internal networks.
• Check firewall forward chain logs and drops (VPN → internal).
• Look for asymmetric routing when clients can connect but can’t reach anything.

Fourth: Is it just DNS (it’s often DNS)?

• Verify pushed DNS servers and search domains.
• Check whether internal DNS is reachable from VPN subnets.
• Confirm split-tunnel clients still route DNS correctly.

Fifth: Is the application the real failure?

• Correlate VPN session with app logs (file server, RDP gateway, SSO).
• Look for account lockouts, MFA prompts, or app-level IP allowlists rejecting VPN IPs.

Detect unauthorized clients: signals, thresholds, and traps

The signals that actually work

Unauthorized VPN clients show up in patterns. Not always “unknown user,” because attackers love valid credentials.
You want multi-signal detection that’s hard to fake.

• New device credential: first-seen cert fingerprint or first-seen WireGuard key.
• Improbable travel: same user authenticates from distant geos within an unrealistic time window.
• Concurrent sessions: same user/cert/key active from two endpoints at once.
• Unexpected client stack: user typically uses corporate-managed client; suddenly shows up with a different client version/OS profile.
• Policy probing: many firewall denies from VPN subnet across ports/subnets (scan-ish behavior).
• After-hours access to sensitive services: correlation of VPN sessions with high-value systems.
• Auth failures preceding success: repeated failures followed by success from same IP (credential guessing) or from different IPs (stuffing).

Thresholds: be specific, then iterate

“Alert on anything weird” is how you get muted. Pick a few thresholds that map to real risk:

• New device credential for a privileged group (admins, finance) → page.
• Two simultaneous sessions for the same cert/key → ticket + temporary lock, unless you allow multi-device explicitly.
• More than N denies to sensitive subnets in 5 minutes from a VPN IP → block that VPN IP and investigate owner.
• Authentication from data center ASNs for normal users → ticket or block, depending on your remote-work model.

Traps that produce false confidence

Don’t mistake “MFA enabled” for “safe.” MFA can be bypassed via session theft, device compromise, or simply because your VPN doesn’t actually enforce it for all paths.
Also, don’t over-trust “known IP ranges” if your workforce uses mobile networks and coffee shop Wi‑Fi. You will block your own CEO on a layover. That’s a career-limiting move.

Joke #2: VPN access control is like office coffee—everyone says they want it “strong,” until it starts keeping them honest.

Three corporate mini-stories (painfully plausible)

1) Incident caused by a wrong assumption: “The certificate CN is the user”

A mid-sized professional services firm rolled out OpenVPN years ago. The original admin generated a single client certificate named client
and copied the same profile to every laptop. It “worked,” which was the only success metric at the time.

Fast forward: a shared mailbox receives an alert from a file server—large downloads of confidential PDFs at 03:17. The VPN logs show a clean connection:
CN client, assigned IP 10.8.0.14. That’s it. No unique identity. No per-device record. No way to differentiate a stolen profile from a legit user.

Security tried to correlate by source public IP. It pointed to a mobile carrier NAT. Helpful, in the way a screen door is helpful on a submarine.
They spent two days interviewing people and rebuilding timelines from endpoint telemetry.

The fix was blunt and expensive: regenerate unique certificates per device, enforce one cert per user/device, and store fingerprints in an inventory.
They also made ifconfig-pool-persist mandatory to stabilize correlation. The uncomfortable lesson: attribution isn’t optional; it’s a design requirement.

2) Optimization that backfired: “Let’s reduce logs to save storage”

Another org moved VPN logs into a central log platform and got sticker shock. Someone suggested dialing down verbosity and dropping “connection noise.”
They kept only authentication failures and a daily summary.

For a few months, it seemed fine. Less ingestion, fewer dashboards. Then an internal audit asked for evidence of who accessed the R&D network over VPN in a specific week.
The team could prove some users authenticated. They could not prove session durations, assigned VPN IPs, or which users overlapped with suspicious firewall events.

The painful part: they still had firewall logs. Lots of them. But without the VPN IP mapping at the time of the event, firewall logs were just a list of 10.8.x.x addresses.
The join key was gone.

They reversed course and implemented a two-tier retention: keep full session logs for a shorter hot period, and keep normalized session records (start, stop, vpn_ip, user, device_id, src_ip)
for longer. Storage costs went up a bit. Audit risk went down a lot. That’s usually the right trade.

3) Boring but correct practice that saved the day: stable IP mapping + off-host logging

A manufacturing company had an unglamorous practice: every VPN client credential was unique and registered, VPN IPs were stable per device, and logs were shipped off-host with TLS.
They didn’t call it “zero trust.” They called it “not having time for nonsense.”

One morning, the SOC flagged unusual access to an internal Git service from a VPN IP. The VPN gateway itself was under load but still running.
The on-call engineer pulled a single query from the log hub: VPN IP → device cert fingerprint → assigned user → source public IP and connection time.

It turned out to be a developer’s laptop infected via a browser extension. The attacker used an active VPN session to pivot to internal services.
Because the logs were centralized and time-synced, the team had a clean timeline: VPN connect, internal scans (firewall denies), Git access attempts, then successful clone.

They disabled that one credential, blocked the VPN IP temporarily, and rotated Git tokens. No need to take down the whole VPN.
This is what “boring controls” buy you: surgical response instead of panic.

Common mistakes: symptom → root cause → fix

1) Symptom: “We can’t tell which user owned a VPN IP during an incident.”

Root cause: No persistent IP mapping, or you only kept firewall logs but not VPN session logs.

Fix: Enable stable mappings (ifconfig-pool-persist in OpenVPN; fixed AllowedIPs per peer in WireGuard; stable virtual IPs in IPsec).
Retain normalized session records long enough to meet audit/IR needs.

2) Symptom: “A fired employee’s laptop still connects.”

Root cause: Credential lifecycle is disconnected from HR/IdP lifecycle; certs/keys aren’t revoked; local configs persist.

Fix: Tie VPN access to centralized identity where possible (IdP/MFA). For cert/key VPNs, implement automated revocation/peer removal on offboarding.

3) Symptom: “Lots of AUTH_FAILED but no idea if it’s attack or user error.”

Root cause: Missing source IP correlation, missing auth backend logs, or lack of baseline metrics.

Fix: Log source IP and auth reason, centralize RADIUS/IdP decision logs, and alert on deviations from baseline by user/IP/ASN.

4) Symptom: “WireGuard is up, but we can’t audit who used it.”

Root cause: No peer inventory mapping keys to owners; changes made by hand on the server.

Fix: Maintain a key registry (CMDB, Git repo with approvals, or a management system). Require change tickets for peer adds/removals and log config changes.

5) Symptom: “VPN connects, but users can’t reach internal apps.”

Root cause: Missing routes, firewall drops, or DNS not pushed/reachable.

Fix: Check routing tables and forward rules; log VPN forward accepts/denies; validate DNS reachability from VPN subnet.

6) Symptom: “We have logs, but queries are slow and useless.”

Root cause: Unparsed text, inconsistent timestamps/timezones, no key fields for joins.

Fix: Normalize into structured events. Enforce UTC, consistent hostname tagging, and include stable identifiers (cert fingerprint/WG key, assigned VPN IP, username).

Checklists / step-by-step plan

Phase 1: Make sessions traceable (this week)

1. Inventory VPN types in use (OpenVPN/WG/IPsec). Kill zombies and duplicates.
2. Ensure logs are written locally and shipped off-host with TLS.
3. Enforce NTP on VPN gateways, auth backends, and log hub.
4. Enable/verify stable VPN IP mapping per device/credential.
5. Record unique device identifiers: cert fingerprint or WireGuard public key.

Phase 2: Build detection that doesn’t cry wolf (2–4 weeks)

1. Parse VPN logs into fields (username, device_id, src_ip, vpn_ip, start/stop, bytes).
2. Join VPN sessions with auth decision logs (RADIUS/IdP) and firewall boundary logs.
3. Create alerts for:
   • first-seen device_id for privileged users
   • concurrent sessions for same device_id/user
   • high deny rates from VPN subnet to sensitive networks
4. Define response: block credential, isolate device, require re-enrollment, or step-up MFA.

Phase 3: Operationalize (ongoing)

1. Quarterly access review: who is in VPN-allowed groups and why.
2. Credential rotation cadence for service accounts and high-privilege users.
3. Test log coverage: simulate a connection and confirm events appear end-to-end in the log platform within minutes.
4. Run tabletop incidents: “unknown device connects and scans internal networks.” Measure time to attribute and contain.

FAQ

1) What’s the minimum set of VPN log fields I need for incident response?

Timestamp (UTC), VPN gateway hostname, username/identity, device identifier (cert fingerprint or WireGuard key), source public IP:port, assigned VPN IP,
session start/stop (or last-seen), and bytes in/out. Without those, correlation becomes guesswork.

2) Are VPN logs enough to prove what a user accessed?

No. VPN logs prove tunnel facts. To prove access, correlate with firewall logs and service logs. Think “session + policy boundary + app event.”

3) How do I detect a copied OpenVPN profile?

Look for the same certificate fingerprint/CN connecting from multiple source IPs concurrently, or from unusual networks for that user.
If you don’t log fingerprints, start there—CN alone is weak.

4) WireGuard doesn’t have usernames. How do I do identity?

Treat the public key as the identity and maintain a registry mapping key → user/device/owner. Log config changes and require approvals for peer additions.
If you need “user logins,” put WireGuard behind an authenticated gateway or integrate with an access broker.

5) How long should we retain VPN logs?

Retain full session logs long enough to cover your realistic detection window (often 30–90 days). Retain normalized session records longer if compliance requires it
(often 90–180+ days). Decide based on risk and audits, not vibes.

6) Should we log all VPN traffic?

Generally no. Log sessions and boundary decisions. Full traffic capture is expensive, invasive, and hard to use. If you need deep inspection, do it selectively and legally.

7) What’s the best single alert for unauthorized VPN access?

“First-seen device credential for a privileged user” is high-signal. Pair it with a containment play: temporarily restrict that session until confirmed.

8) How do we stop VPN logs from becoming a privacy problem?

Log metadata, not payload. Limit access to logs, define retention, and document purpose (security/operations). Apply least privilege to log queries and exports.

9) What if our VPN is managed by an appliance and logs are limited?

Pull what you can (session start/stop, assigned IP, user identity) and supplement with firewall logs and IdP/RADIUS logs.
If the appliance can’t export in near real-time, you have an operational risk—escalate it as such.

Conclusion: next steps that survive Monday morning

Office VPN logging is not about collecting more text. It’s about building a chain of evidence: identity → device → session → policy boundaries → critical services.
When you do it right, unauthorized clients don’t get “caught by vibes.” They get caught by mismatched identifiers and unnatural behavior.

Do these next:

1. Make device credentials unique (cert fingerprint or WireGuard key per device) and inventory them.
2. Ensure stable VPN IP mapping and retain normalized session records long enough to investigate real incidents.
3. Ship logs off-host with TLS, enforce time sync, and parse logs into structured fields.
4. Alert on first-seen device credentials for privileged users, concurrent sessions, and high deny rates to sensitive networks.
5. Practice the fast diagnosis playbook until it’s muscle memory.

The goal isn’t perfection. The goal is that when someone asks “who connected and what did they touch,” you answer with evidence, not a meeting.