Why does the VPN client have access to all interfaces instead of being restricted by the subnet and the disable forwarding option?

Context

In my Debian Linux infrastructure, I manage several network interfaces with specific roles.

• Firewall rules: No iptables/nftables rules are currently applied. All chains have a default policy set to ACCEPT.
• Kernel configuration: IPv4 forwarding is disabled (net.ipv4.ip_forward = 0).

---

Goal

The goal is to strictly limit network communications in the infrastructure:

When a computer connects to the VPN via the wg0 interface, it should only be able to communicate with a specific virtual machine located on the vmbr0 bridge.

The objective is to ensure complete isolation between interfaces and restrict traffic to this specific use case.

---

Reproducing the Setup

WireGuard Configuration (fake information)

To replicate the environment, here is a basic WireGuard configuration for two Linux machines:

Machine 1: VPN Server (fake information)

Interface: wg0

1. Key generation (example keys, generated via wg genkey and wg pubkey):

   • Private key: 9+9N5R5Dje2dmldDtrjQoBb3AFOWhOAyZ9mfWQKn7QY=
   • Public key: Ci4z9W+n8gfrFRRGZs3DNMHmKk1TFNG9QXGV7zg5OkE=

2. WireGuard configuration: (fake information)

   File /etc/wireguard/wg0.conf:

   [Interface] PrivateKey = 9+9N5R5Dje2dmldDtrjQoBb3AFOWhOAyZ9mfWQKn7QY= Address = 10.0.0.1/24 ListenPort = 51820 [Peer] PublicKey = YdC5+zMdKj5cRW2WlAv7GDETx+gjZukOmeC+lkJZ8is= AllowedIPs = 10.0.0.2/32 

3. Commands to apply:

   sudo wg-quick up wg0 sudo systemctl enable wg-quick@wg0 

Machine 2: VPN Client (fake information)

Interface: wg0

1. Key generation:

   • Private key: mWjXaRlvJjThhf9ZZpaAWwdY0Puvy0k9fGy7prlzvV8=
   • Public key: YdC5+zMdKj5cRW2WlAv7GDETx+gjZukOmeC+lkJZ8is=

2. WireGuard configuration:

   File /etc/wireguard/wg0.conf:

   [Interface] PrivateKey = mWjXaRlvJjThhf9ZZpaAWwdY0Puvy0k9fGy7prlzvV8= Address = 10.0.0.2/24 [Peer] PublicKey = Ci4z9W+n8gfrFRRGZs3DNMHmKk1TFNG9QXGV7zg5OkE= Endpoint = <SERVER_IP>:51820 AllowedIPs = 10.0.0.1/24, 172.16.0.0/16, 192.0.2.0/24 PersistentKeepalive = 25 

3. Commands to apply:

   sudo wg-quick up wg0 sudo systemctl enable wg-quick@wg0 

These configurations establish a simple connection between the VPN server (10.0.0.1) and the client (10.0.0.2). This setup forms the basis for testing the described requirement.

Bridge

sudo brctl addbr vmbr0 sudo ip addr add 172.16.0.1/16 dev vmbr0 sudo ip link set dev vmbr0 up 

Problem

When a client connects to the VPN via the wg0 interface, the following issues are observed:

Access to all interfaces: Despite different subnets and IPv4 forwarding being disabled, the VPN client can successfully ping all network interfaces, including eth0 and vmbr0.

Packet visibility: By running tcpdump on each interface (eth0, vmbr0, and wg0), it is observed that the ping packets only traverse the wg0 interface. However, responses are still received when the client pings other interfaces.

Service exposure: If a service is running on any interface, such as:

python3 -m http.server --bind 192.0.2.1 

(bound to the eth0 IP address 192.0.2.1/24), the VPN client has access to this service.

Interface down scenario: If an interface (e.g., eth0) is brought down using:

ip link set dev eth0 down 

the VPN client can still successfully ping the IP address associated with the downed interface and access the running service (e.g., the HTTP server). This behavior persists regardless of the operational state of the interface.

Restricted VM issue: When adding a virtual machine on the vmbr0 bridge, the VPN client is unable to ping it. (Normal but why can i ping the bridge)

Request for Assistance

Given the above configuration and observed issues:

• Why does the VPN client have access to all interfaces (eth0, vmbr0) instead of being restricted by the subnet and the disable forwarding option ?
• How can the VPN client still access services or ping IPs on downed interfaces?

Any insights or solutions would be greatly appreciated!