os-tailscale: ICMP traffic bypasses firewall rules on tailscale0 interface

Title:
os-tailscale: ICMP traffic bypasses firewall rules on tailscale0 interface

---

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• The title contains the plugin to which this issue belongs

Describe the bug

ICMP (ping) traffic from a Tailscale/Headscale client reaches a LAN host even though no pass rule for ICMP exists on the tailscale0 interface. Only a single pass rule is configured on this interface (TCP/22 to one specific host), yet ICMP echo requests to that same host are not blocked, despite there being no matching pass rule and a default-deny posture.

This looks related to #5029 ("os-tailscale ignores Firewall Rules altogether"), which focused on outbound NAT/gateway/exit-node routing. This report isolates the same underlying symptom for a simpler, minimal case (inbound ICMP, single missing rule) and includes a pfctl rule dump showing no rule matches the traffic that is nonetheless passed.

Last known working version: not tested on a previous version, this is the first time I've configured os-tailscale firewall rules.

To Reproduce

1. Go to VPN → Tailscale, set up an os-tailscale instance against a Headscale control plane, interface assigned as HeadscaleLAN (tailscale0).
2. Go to Firewall → Rules → HeadscaleLAN and configure exactly one pass rule:
   • Protocol: TCP, Source: any, Destination: 192.168.1.45, Destination port: 22 (SSH)
3. Apply changes.
4. On the firewall shell, confirm this is the only pass rule on the interface:

   pfctl -vvsr | grep -B1 "tailscale0"
   

5. From a device joined to the same tailnet, run:

   ping 192.168.1.45
   

Expected behavior

The ping should be dropped, since there is no pass rule for ICMP on tailscale0 and the default policy is deny.

Screenshots

Not applicable, issue reproduced via shell.

Relevant log files

pfctl -vvsr | grep -B1 "tailscale0" output:

root@opnsense:~ # pfctl -vvsr | grep -B1 "tailscale0"
  [ Last Active Time: N/A ]
@0 block drop in log on ! tailscale0 inet6 from fd7a:115c:a1e0::/48 to any
--
  [ Last Active Time: N/A ]
@8 block drop in log on ! tailscale0 inet from 100.64.0.8 to any
--
  [ Last Active Time: Fri Jul 31 10:56:51 2026 ]
@97 pass in quick on tailscale0 inet proto tcp from any to 192.168.1.45 port = ssh flags S/SA keep state label "88b4bfa2bc1940368e08301007c3b9ac"

Ping from a tailnet-joined Windows client:

PS C:\Users\sbin> ping 192.168.1.45
Pinging 192.168.1.45 with 32 bytes of data:
Reply from 192.168.1.45: bytes=32 time=75ms TTL=64
Reply from 192.168.1.45: bytes=32 time=10ms TTL=64

Ping statistics for 192.168.1.45:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss)

No rule on tailscale0 permits ICMP to 192.168.1.45, yet the ping succeeds. The SSH rule (port 22 only) works correctly and is properly restricted to that port, so the discrepancy appears specific to how ICMP traffic on this interface is evaluated — or not evaluated — against the rule set.

Additional context

Related: #5029, which reports firewall rules on the tailscale interface not applying at all, focused on NAT/gateway/exit-node behavior. This report narrows the same symptom to a minimal, reproducible case (single protocol, single missing rule, clear pf rule dump showing no match), which may help pinpoint whether ICMP specifically is special-cased, or whether the interface as a whole is not fully integrated into the pf rule evaluation path.

Environment

OPNsense 26.7.1_1 (amd64).
FreeBSD 15.1-RELEASE-p1.
os-tailscale plugin, configured against a Headscale control plane (not the default Tailscale coordination server).
Interface tailscale0, assigned as HeadscaleLAN, tailnet address 100.64.0.8/32.

Start in the os-tailscale plugin and reproduce the setup from VPN → Tailscale with the assigned tailscale0 interface and its single TCP rule. Inspect the pfctl rule dump and compare the behavior with related issue #5029; done means ICMP traffic to 192.168.1.45 is blocked while the SSH rule continues to work.