VPN logs — IKE logs, charon, WireGuard, the diagnostic capture

VPN tunnels silently fail more often than any other component on a VyOS router. The tunnel appears in the configuration but no traffic flows; the operator doesn’t know why because the logs are empty or too sparse. The defensive pattern: every VPN tunnel has logging enabled, every tunnel state change is captured, and the operator can quickly identify the root cause from the logs.

This lesson covers the VPN logging configuration on VyOS 1.5 LTS, the IPsec IKE (charon) logs, the WireGuard operational commands, the diagnostic packet capture, and the production failure modes where the VPN tunnel silently fails.

The VPN logging architecture

flowchart LR
  subgraph IPsec["IPsec"]
    CH["charon<br/>strongSwan IKE daemon"] --> LOG1["/var/log/charon.log"]
  end
  subgraph WG["WireGuard"]
    WK["wg-quick / wg"] --> LOG2["kernel ring buffer<br/>dmesg"]
    WK --> CMD["wg show"]
  end
  CH --> CENTRAL["Central syslog server"]
  WK --> CENTRAL

The two VPN stacks have different logging models:

• IPsec (strongSwan / charon) — charon is a userspace daemon; it logs to /var/log/charon.log via syslog. The operator can configure the log level and the destination.
• WireGuard — WireGuard is a kernel module; it does not have a daemon. State is queried via wg show. Recent events are in the kernel ring buffer (dmesg).

IPsec — configuring charon logging

configure
set vpn ipsec logging log-level '1'
set vpn ipsec logging log-mnemonics 'enable'
commit
save

The configuration sets the charon log level:

• 0 — silent (only audit messages).
• 1 — audit messages only (the default).
• 2 — audit + control messages (recommended for troubleshooting).
• 3 — audit + control + IKE negotiation messages (verbose).
• 4 — audit + control + IKE negotiation + raw packet dumps (very verbose; can fill the disk).

The production default is 1 (audit only); the operator raises to 2 or 3 when troubleshooting an issue.

log-mnemonics adds the IKE message mnemonic (e.g., IKE_SA_INIT, IKE_AUTH) to the log; without mnemonics, the log is harder to interpret.

Interpreting charon log messages

A typical IPsec connection establishment:

Aug 15 12:00:01 R1 charon: 09[IKE] <1> initiating IKE_SA (conn my-vpn) to 203.0.113.50
Aug 15 12:00:01 R1 charon: 09[IKE] <1> IKE_SA (conn my-vpn) state transition: CREATED => CONNECTING
Aug 15 12:00:01 R1 charon: 09[IKE] <1> sending IKE_SA_INIT request
Aug 15 12:00:02 R1 charon: 09[IKE] <1> received IKE_SA_INIT response
Aug 15 12:00:02 R1 charon: 09[IKE] <1> IKE_SA (conn my-vpn) state transition: CONNECTING => ESTABLISHED
Aug 15 12:00:02 R1 charon: 09[CHD] <1> CHILD_SA (conn my-vpn) state transition: CREATED => INSTALLING
Aug 15 12:00:02 R1 charon: 09[CHD] <1> CHD SA (conn my-vpn) established

The operator reads the log to identify:

• The connection name (conn my-vpn).
• The remote peer (203.0.113.50).
• The state transitions (CREATED → CONNECTING → ESTABLISHED).
• The IKE message exchange (IKE_SA_INIT, IKE_AUTH).
• The CHILD_SA establishment.

A failing connection shows errors instead of state transitions:

Aug 15 12:00:01 R1 charon: 09[IKE] <1> initiating IKE_SA (conn my-vpn) to 203.0.113.50
Aug 15 12:00:01 R1 charon: 09[IKE] <1> IKE_SA (conn my-vpn) state transition: CREATED => CONNECTING
Aug 15 12:01:01 R1 charon: 09[IKE] <1> sending IKE_SA_INIT request
Aug 15 12:01:31 R1 charon: 13[IKE] <1> giving up after 30 retries

The “giving up after 30 retries” indicates the peer is not responding. The operator checks the peer’s IP, the firewall, and the peer’s configuration.

IPsec — operational commands

show vpn ipsec sa
show vpn ike sa
show vpn ipsec status

show vpn ipsec sa shows the IPsec Security Associations (CHILD_SAs):

vyos@R1:~$ show vpn ipsec sa
Connection                State    Bytes In    Bytes Out    Packets In    Packets Out
my-vpn[1]: ESTABLISHED    0.5 days 1234567     9876543      12345         9876

The output shows the connection name, the state, and the byte / packet counters. A working SA has ESTABLISHED state and incrementing counters.

show vpn ike sa shows the IKE Security Associations:

vyos@R1:~$ show vpn ike sa
Peer                             Conn     ID    State    Time    Remote ID
203.0.113.50                     my-vpn   1     ESTABLISHED  0.5 days

A working IKE SA has ESTABLISHED state. A failing SA has CREATED or CONNECTING state.

WireGuard — operational commands

show interfaces wireguard
wg show
wg show wg0

show interfaces wireguard shows the WireGuard interface configuration:

vyos@R1:~$ show interfaces wireguard
Codes: U - Up, D - Down, A - Admin Down, L - Layer
Interface    State    Description
wg0          U        site-to-site-vpn

wg show (without arguments) shows all WireGuard interfaces:

vyos@R1:~$ wg show
interface: wg0
  public key: <server-public-key>
  private key: (hidden)
  listening port: 51820

peer: <peer-public-key>
  endpoint: 203.0.113.50:51820
  allowed ips: 10.0.0.0/24
  latest handshake: 1 minute, 30 seconds ago
  transfer: 1.23 MB received, 4.56 MB sent
  persistent keepalive: every 25 seconds

The operator reads the output to identify:

• The interface (wg0).
• The public key (for the operator to share with the peer).
• The peer’s endpoint (203.0.113.50:51820).
• The latest handshake (when was the last successful handshake?).
• The transfer (bytes received and sent).

A working peer has latest handshake within the last 2-3 minutes (WireGuard keeps the connection alive with periodic handshakes) and non-zero transfer.

Capturing VPN traffic

For detailed forensic analysis, the operator captures the IKE / ESP / WireGuard traffic:

tcpdump -i eth0 -n -p udp port 500 or udp port 4500 or udp port 51820 -w /tmp/vpn.pcap

• UDP 500 — IKEv2 main mode.
• UDP 4500 — IKEv2 NAT traversal / ESP-in-UDP.
• UDP 51820 (or configured port) — WireGuard.

The capture shows the IKE message exchange (Initiator → Responder → … → Established) or the WireGuard handshake. The operator correlates the capture with the charon log or wg show output.

How the result is validated

show vpn ipsec sa
show vpn ike sa
wg show
tcpdump -i eth0 -n -p udp port 500 or udp port 4500 or udp port 51820
journalctl -u strongswan
dmesg | grep -i wireguard

A working VPN setup:

• IPsec SAs are ESTABLISHED with incrementing counters.
• WireGuard peers have recent handshakes and non-zero transfer.
• The captures show the IKE / WireGuard handshakes.
• The logs are exported to the central syslog server.

How it fails

The production failure modes a routing engineer must recognise:

• IPsec tunnel silently fails. The configuration is correct, but the IKE SA is in CREATED state, not ESTABLISHED. The operator sees no traffic flow. The fix: review the charon log for the IKE negotiation; check the peer’s IP, the firewall, the peer’s configuration.
• WireGuard peer handshake timeout. The peer’s latest handshake is hours old. The fix: check the peer’s endpoint IP, the firewall, the peer’s WireGuard daemon.
• IPsec authentication mismatch. The IKE SA fails to establish because the pre-shared key or certificate is wrong. The fix: verify the authentication on both sides.
• WireGuard key mismatch. The peer’s public key doesn’t match the configured peer. The fix: update the public key on one side.
• Firewall blocks IKE / WireGuard. The firewall blocks UDP 500 / 4500 / 51820. The IKE or WireGuard handshake cannot reach the peer. The fix: open the firewall for the VPN traffic.
• Endpoint changes. The peer’s IP changes (DHCP, mobile network). WireGuard and IPsec both fail to reach the old endpoint. The fix: update the endpoint or use a dynamic DNS name.

Rollback

The recovery from a broken VPN configuration:

• Wrong pre-shared key: delete vpn ipsec ike-group <name> authentication pre-shared-secret and re-add the correct secret.
• Wrong peer IP: set vpn ipsec site-to-site peer <name> remote-address with the correct IP.
• Wrong WireGuard key: set interfaces wireguard wg0 peer <key> with the correct public key.
• Firewall blocks VPN: add firewall rules for UDP 500 / 4500 / 51820.

The VyOS configuration rollback (rollback N) restores the previous configuration if the VPN change breaks the tunnel.

Production discipline

Cross-course references

• XLVIII-VyOS-Logging (vyos-xlviii-01-local-logging, vyos-xlviii-05-remote-syslog) cover the rest of the logging subsystem.
• XLI-VyOS-WireGuard covers the WireGuard configuration.
• XLII-VyOS-IPsec covers the IPsec configuration.
• XLIII-VyOS-VPNRouting covers the routing over VPN tunnels.

Quiz