A VPN Peer Pings Other Interfaces Because They Are Local
The local routing table sends packets to any address the host owns, whatever interface it sits on. Forwarding settings never enter that path.
A WireGuard client connects and pings an address on a completely different interface, and the reply arrives. Captures show the request only on the tunnel. Nothing is broken, and the forwarding setting that was carefully disabled has nothing to do with it. This is a comparison between two paths that look similar in a diagram and are completely different in the kernel.
One path forwards packets for somebody else; the other delivers them to the host itself.
A Packet Addressed to the Host Stays in the Host
The remote client sends an IP packet to an address the host owns. Routing asks one question about that packet: is this destination local? Every address the host holds appears in the local routing table, and that table is consulted ahead of the main one, so the packet goes to the host's own stack instead of out of another interface. The answer is generated locally, and it travels back through the tunnel because that is where the query came from.
That is the whole mechanism. No forwarding occurs, no interface state change is involved, and the address in question does not need to be reachable from anywhere else.
Why ip_forward Does Not Apply
Forwarding governs packets that must leave through a different interface than the one they arrived on. A ping to the host itself never takes that path: the packet is consumed locally and the reply is generated locally. Setting net.ipv4.ip_forward=0 therefore changes nothing here, and a rule in the forward chain never sees the traffic. The correct control sits on the input path, scoped by incoming interface or source.
That is why disabling forwarding and assuming the host is isolated produces a false sense of security.
Read the Local Table That Decided
ip rule show normally reports a rule at priority zero sending all lookups to the local table first, and ip route show table local lists the host's own addresses with local scope. That table includes addresses on interfaces that are administratively down but still configured. IPv4 addresses assigned statically usually survive a link drop, which is how a ping to a downed bridge can still succeed and surprise the operator.
IPv6 disagrees on exactly this point. Its addresses are ordinarily withdrawn when the link drops, unless keep_addr_on_down is set. Compare the families instead of assuming one rule covers both.
What a Peer Actually Reaches
An answer from the router's own address on a segment says nothing about the machines behind that segment. The peer cannot reach a host behind the other interface through this path; it only reaches addresses the router itself owns. Testing a service on a separate LAN host, rather than pinging the router's address, is what establishes whether forwarding is permitted at all.
Restricting a peer to services bound on the tunnel address is an input policy question. Permit the wanted service on the tunnel interface and restrict the sources that may use it, because the packet genuinely arrives there.
Check for addresses you meant to retire as well. Removing an address from an interface is more reliable than stacking firewall rules on top of a stale one.