Yes, with that section in the config file, the WG client on the laptop opens an UDP socket on the port 51820 of all available network adapters and uses the socket to send / receive WG packets (the outer packets of the tunnel).
The [Peer] listed below that is the information about the WG running on the RouterOS router device. Not the information about the laptop's WG. The laptop's WG informations are already under the [Interface] section.
The [Peer] sections of the config file (there can be multiple, not only one) contains information about the other remote side(s) of the tunnel.
And on the RouterOS router it's similar: You define one WG interface (/interface wireguard add), then you add peers to the interface (/interface wireguard peers add). The peer entries added there also contain information about the remote parties (like the tablet or the laptop), not about the router device.
That's how it is intended to work. On the laptop, when the WG tunnel is active, WG will install routes (if running Windows you can run route print in the command line to see them, for Linux run ip route) in the laptop's routing table, by using the information listed by AllowedIPs of all the [Peer] sections of the active WG tunnel. In the example config above, there will be routes installed for destinations 192.168.0.0/23, 10.0.0.0/8, and 192.168.216.1/32, that have the tunnel network adapter (WG creates this virtual network adapter on the laptop when the tunnel is active) as gateway.
Now when you send something with the destination 10.x.y.z and WG is active, the operating system on the laptop will consult its routing table and see that the packet should be sent using the virtual network adapter created by WG. WG which runs behind this adapter will take the packet see the destination 10.x.y.z and scan the peers of the active WG instance. It will find the peer that has 10.0.0.0/8 that can contain this address. It will use the other information listed under that [Peer] section (Endpoint, PublicKey and PreshareKey) to establish the handshake with that remote party (if the handshake is not already active) and then encrypt and encapsulate the packet that needs to be sent (packet with destination 10.x.y.z) and send to that remote endpoint.
As you can see, this look similar to what I described above when the router needed to send the response packet to the remote A9+ tablet, it also had to use the routing table to know that back-to-home-vpn is the gateway interface, and the WG associated with that interface also needs to scan its peer list to find the suitable peer (the tablet).
So now what happens if you remove 10.0.0.0/8 from the AllowedIPs list of that [Peer] section?
-
First, the WG client application will no longer install a route for the destination 10.0.0.0/8 in the laptop's routing table anymore. You can verify this by listing the routes using the command above when the tunnel is actively running.
Which means when some app/program on the laptop needs to send a packet to destination 10.x.y.z, there is no more route that tells the operating system to use the virtual tunnel network adapter to send the packet. Instead some other matching route, such as the default 0.0.0.0/0 route with some other gateway will be used, and the packet will not be sent using WG.
-
Second, even if you've manually manipulated the routing table and add routes, so that packets with destination 10.x.y.z will have the WG tunnel adapter as gateway, when WG needs to process this packet, it will scan the list of peers to find a suitable one to send the 10.x.y.z destination packet too. But now none of the [Peer] have anything in there AllowedIPs ranges that can contain the 10.x.y.z address. WG cannot find a suitable peer, and the packet cannot be sent.
As a result, you on your laptop cannot access any resources on your 10.0.0.0/8 network.
To be more correct, the start of this question should be "But in the WG configuration on the router...". Yes, on the peer definition associated with the laptop on the router, you only need to list 192.168.216.4/32 because:
-
The router will use this subnet when checking whether it should accept the packets sent by the laptop or not. The laptop will always set 192.168.216.4 as source address of the packets it sends through the tunnel, so this is fine and fully enough.
-
When packets need to be sent to the laptop through the tunnel (including all the response packets to the request that the laptop previously sent), the destination address of the packets will all be 192.168.216.4. So when WG on the router scans the list of peers for a suitable candidate, this peer with allowed-address=192.168.216.4/32 can satisfy the check and will be picked up.
Of course, if on the router the peer list only has one item, then nothing prevents you to put allowed-address=0.0.0.0/0 for this singular item. And this peer will also be picked when packets need to be sent to 192.168.216.4 and it works too. But if there is more than one peers listed then the peer having allowed-address=0.0.0.0/0 will cause problem, because it might catch all the packets that were intended for the other peers. That's why it's important to not have overlapping address ranges among the peers of the same interface.
And if the WG tunnel is not between the laptop and the RouterOS router (Road Warrior configuration), but between two routers (site-to-site configuration) where you want the LAN behind the two routers to see each other, then having only allowed-address=192.168.216.4/32 will not be enough. Because with that only packet destined to the sole router device can be sent (and received from only that address). If you want to send packets to the LANs behind that router too, then the subnet of those LANs should also be added to the list. This also has the effects that when the devices in those LANs send packets to this side of the tunnel, the packets will have source addresses in those address ranges too, and will be accepted by this side of the tunnel because allowed-address can match those addresses.
. The WG app on the phone is just like WG on the router, you define one interface (so it's called on the router) / tunnel (so it's called on the phone), which specify the port where WG listens on the device, plus the key pair of the device for that tunnel.
