Skip to main content
RunBook Academy

← All break/fix scenarios in OPNsense

intermediateNetworking~25 min

Break/Fix: WireGuard Tunnel Up But No Traffic Flows

Reported symptoms

  • ●WireGuard peer shows recent handshake and transfer counters stuck at 0 B
  • ●Ping from the WireGuard subnet to the remote endpoint fails
  • ●wg show on the firewall lists the peer as up but rx/tx never increment

Evidence

  • · wg show wg0: latest handshake: 12 seconds ago, transfer: 0 B received, 0 B sent
  • · pfctl -ss | grep wg0: empty — no state entries
  • · tcpdump -ni wg0: ARP requests from the peer are visible but never answered
Diagnosis and resolutionclick to reveal

Root cause

The WireGuard tunnel is established, but no rule or route is carrying traffic — the AllowedIPs on the local side do not include the peer subnet, or the wg interface has no associated firewall rule group.

Remediation

1. On the local peer, set AllowedIPs to cover the remote subnet (e.g. 10.10.0.0/24, not just the peer address). 2. On the WireGuard instance, confirm "Allow" rules exist on the wg interface for the assigned tunnel network in both directions. 3. Apply and re-test ping.

Verification

wg show transfer counters increment on both sides; ping across the tunnel returns; pfctl -ss shows states on wg0.

Prevention

Treat AllowedIPs as both routing and firewall: anything you want to reach through the tunnel must be in AllowedIPs. Add a baseline rule group on the WireGuard instance that allows traffic to and from the tunnel network, and test it with a single ping before adding services.

Scenario

You are operating an OPNsense edge with a WireGuard site-to-site tunnel to a remote office. The following symptoms appear:

  • WireGuard peer shows recent handshake and transfer counters stuck at 0 B
  • Ping from the WireGuard subnet to the remote endpoint fails
  • wg show on the firewall lists the peer as up but rx/tx never increment

Available evidence:

  • wg show wg0: latest handshake: 12 seconds ago, transfer: 0 B received, 0 B sent
  • pfctl -ss | grep wg0: empty — no state entries
  • tcpdump -ni wg0: ARP requests from the peer are visible but never answered

Your task

Determine the cause, recover, document, and validate.

Investigation

The investigation follows the discipline taught in Part XXIII:

  1. Form hypothesis, find evidence, test, validate.
  2. Use the available evidence above to bound the search.
  3. Reach one of the likely root causes.

Recovery procedure

(Do not reveal until you have reasoned through the problem.)

  1. Identify the failing component.
  2. Apply the remediation pathway.
  3. Validate with the verification step.
  4. Document the incident.

Remediation

  1. On the local peer, set AllowedIPs to cover the remote subnet (e.g. 10.10.0.0/24, not just the peer address). 2. On the WireGuard instance, confirm “Allow” rules exist on the wg interface for the assigned tunnel network in both directions. 3. Apply and re-test ping.

Verification

wg show transfer counters increment on both sides; ping across the tunnel returns; pfctl -ss shows states on wg0.

Rollback

Remove the Allow rules on the wg interface; revert AllowedIPs to the previous values.

Prevention

Treat AllowedIPs as both routing and firewall: anything you want to reach through the tunnel must be in AllowedIPs. Add a baseline rule group on the WireGuard instance that allows traffic to and from the tunnel network, and test it with a single ping before adding services.