Capture on VLANs and tunnels — seeing traffic that lives on the wrong interface

The firewall operator who captures only on the obvious interfaces (LAN, WAN) misses traffic that lives on a VLAN, a bridge, or a tunnel. VLAN tags are invisible to BPF on the parent interface; tunnel encapsulations hide the inner packet from BPF on the underlying interface. The operator must capture on the interface that carries the inner packet, not the outer one.

This lesson covers capturing on VLAN interfaces, bridge members, WireGuard, IPsec, and OpenVPN tunnels, and the discipline of choosing the right interface.

Capturing on VLAN interfaces

OPNsense creates VLAN interfaces as parent_vlanID — for example, igb0_vlan10 for VLAN 10 on parent igb0. The operator captures on the VLAN interface to see only the tagged traffic for that VLAN; the parent interface sees all VLANs as separate frames plus the untagged traffic.

The discipline:

• Capture on the parent (igb0) to see all VLANs mixed. Each frame has its 802.1Q tag visible (use -e to see the tag in the link header).
• Capture on the VLAN interface (igb0_vlan10) to see only VLAN 10 traffic. The kernel strips the tag before delivering the frame to BPF; the operator sees normal Ethernet frames with no 802.1Q tag.
• Use BPF vlan N to filter on the parent. tcpdump -ni igb0 vlan 10 is equivalent to capturing on the VLAN interface but uses the parent BPF tap.

$ tcpdump -ni igb0_vlan10 -c 1

12:34:56.789012 aa:bb:cc:11:22:33 > 66:77:88:99:aa:bb, IPv4, length 84: 192.0.2.50.51820 > 8.8.8.8.53: UDP, length 42

Capturing on bridge members

OPNsense bridges (e.g. bridge0 with members igb1 and igb2) carry traffic between the member interfaces. Capturing on the bridge sees frames forwarded by the bridge; capturing on a member interface sees frames arriving or leaving that member. The two views overlap but are not identical.

The discipline:

• Capture on bridge0 to see what the bridge is forwarding. Both ingress and egress traffic on the bridge are visible.
• Capture on igb1 to see what is arriving on that physical interface. This includes frames the bridge forwards, frames destined to the firewall itself, and frames the bridge drops.
• Avoid double-counting. A frame that enters igb1 and exits igb2 via the bridge appears on both member captures and on the bridge capture. The operator who sums counts across interfaces overcounts.

The trap is that bridges in OPNsense run learning mode by default — the bridge forwards based on MAC tables, and broadcast frames are flooded. A capture on the bridge may show frames the firewall never routed (because the bridge forwarded them directly between members). The operator must check whether the firewall was involved by looking at the bridge forwarding database.

Capturing on WireGuard tunnels

WireGuard creates a tunnel interface (wg0, wg1, etc.). The operator captures on the tunnel interface to see the inner (post-decapsulation) traffic — the IP packets that the WireGuard peer sees. Capturing on the underlying interface (e.g. igb0) shows only the outer UDP/51820 frames carrying the encrypted payload.

The discipline:

• Capture on wg0 to debug WireGuard traffic. The frames are decrypted IP packets; the operator sees the inner source, destination, and port.
• Capture on the underlying interface to debug WireGuard handshake or encapsulation. The frames are UDP/51820 with the encrypted payload; the operator sees only the outer header.
• Use wg show to check the tunnel state. wg show wg0 prints the peer’s latest handshake, transfer counters, and endpoint. If the handshake is fresh and counters are non-zero, the tunnel is alive — the bug is somewhere else.

$ tcpdump -ni wg0 -c 1

12:34:56.789012 aa:bb:cc:11:22:33 > 66:77:88:99:aa:bb, IPv4, length 84: 10.0.0.1.51820 > 10.0.0.2.443: Flags [S], seq 1234567890, win 65535, options [mss 1420,sackOK,ts val 1234567 ecr 0,nop,wscale 7], length 0

Capturing on IPsec tunnels

IPsec in transport mode has no tunnel interface; the encrypted traffic appears on the underlying interface as ESP (protocol 50) or AH (protocol 51) packets. IPsec in tunnel mode creates a ipsec0 interface (or similar, depending on the configuration) that shows the inner traffic after decryption.

The discipline:

• Capture on ipsec0 (or the configured tunnel interface) to debug inner traffic. The frames are decrypted IP packets.
• Capture on the underlying interface to debug ESP/AH. The frames are ESP (protocol 50) — the encrypted payload is not visible to BPF.
• Use setkey -D to check SAD entries. setkey -D prints the Security Association Database — the keys, SPI, and tunnel endpoints.

Capturing on OpenVPN tunnels

OpenVPN creates a tunnel interface (ovpn0, ovpn1, etc.) for each running tunnel. The operator captures on the tunnel interface to see the inner (post-decapsulation) traffic. Capturing on the underlying interface shows either the OpenVPN UDP packets (for UDP-based tunnels) or TCP (for TCP-based tunnels).

The discipline:

• Capture on ovpn0 to debug inner traffic. The frames are decrypted IP packets.
• Capture on the underlying interface to debug handshake or encapsulation. The frames are UDP/1194 (or TCP/443 for stealth configurations).
• Check openvpn-status.log for tunnel state. The status log shows the connected clients, their virtual IPs, and transfer counters.

Choosing the right interface — a decision tree

The operator must choose the capture interface based on the question:

Question: "Is the firewall forwarding traffic from host A?"
  ├── A is on a VLAN → capture on the VLAN interface
  ├── A is on a bridge → capture on the bridge interface
  ├── A is on a tunnel → capture on the tunnel interface
  └── A is on a physical interface → capture on the physical interface

Question: "Why is the tunnel not coming up?"
  └── Capture on the underlying interface — the tunnel is the problem

Question: "What is the peer sending through the tunnel?"
  └── Capture on the tunnel interface — the inner packet is the question

The trap is to capture on the “obvious” interface when the traffic actually lives somewhere else. The operator who runs tcpdump on igb0 to debug a WireGuard tunnel sees only outer UDP frames and concludes the tunnel is dead — when in fact the tunnel is up and the inner traffic is fine.

The encapsulation layers in OPNsense

A typical OPNsense deployment has multiple encapsulation layers:

• VLAN tags on trunk ports.
• Bridge forwarding between members.
• WireGuard or IPsec tunnels to remote sites.
• OpenVPN for remote access.

The operator must know which encapsulation a given flow crosses before choosing the capture interface. The discipline:

• Trace the path. From source to destination, list each interface and encapsulation in order.
• Capture at the right point. The interface closest to the question is the right point.
• Cross-reference with the routing table. netstat -rn shows the egress interface for a given destination; the capture interface should match.

Summary

• VLAN interfaces (igb0_vlan10) carry only the VLAN’s traffic; the 802.1Q tag is stripped before BPF sees the frame.
• Bridge captures show what the bridge forwards; member captures show what arrives on that member — the views overlap but are not identical.
• Tunnel interfaces (WireGuard, IPsec tunnel mode, OpenVPN) carry the inner, post-decapsulation traffic; the underlying interface carries only the encrypted outer frame.
• The decision tree: VLAN → VLAN interface; bridge → bridge interface; tunnel → tunnel interface.
• ESP encryption hides the inner header; capture on the tunnel interface to debug inner traffic.