Does Your VM Use the Host VPN? Test It From Inside the Guest
The host's exit address says nothing about a guest's routes. Record the network mode, check the guest route and resolver, then test the failure case.
You check the host's public IP, it shows the VPN, and you conclude the VM is covered. That conclusion is not supported by the test. A guest has its own routing table, its own resolver and its own interfaces, and the host's exit address says nothing about them.
The test has to run inside the guest, and it has to name what it measured.
Start inside the guest, not in the host browser
Record the hypervisor network mode first: NAT, bridged, host-only or macvtap. In NAT mode the host routes the guest's traffic, so the host's tunnel may or may not apply depending on how the client installs routes. In bridged mode the guest is a peer on the physical LAN and the host's tunnel is irrelevant. Those two modes produce opposite answers from the same host configuration.
Write the mode down before you change anything, because it determines what the result can mean.
Make one request whose destination you know
Use an innocuous request to a service that reports the source address it saw. Then check the guest's own routing decision for that destination: ip route get 203.0.113.5 prints the interface and gateway the guest will use.
If the interface is the guest's normal NIC, the traffic is not going through a tunnel inside the guest.
A second adapter, a proxy setting or a guest-side VPN client can change the answer for one application and not another. Test the application you actually care about, not a generic request from a shell.
Check the resolver separately
A changed exit address does not tell you which resolver handled the hostname. Query the name explicitly with the tool that matches the platform, and note which server answered. Split DNS means the resolver question and the routing question have different answers.
Those two can diverge in either direction, and the divergence is often the actual bug.
On a systemd host, resolvectl query names the interface and the DNS server behind the answer. Older setups show the server in dig output. Either way the point is to see which server replied, not just whether a reply arrived.
Test the failure policy, not just the success
If the requirement is that no traffic leaves outside the tunnel, a successful request proves nothing. Use the client's supported controlled failure test: stop the tunnel the supported way and see whether a new guest request is blocked. Do not assume the host client's kill switch covers every virtual forwarding arrangement. Its documented scope is the only thing you can rely on.
A guest that falls back to the physical NIC when the tunnel drops is doing exactly what NAT mode allows.
Record the mode and the scope
Write down the hypervisor mode, the guest interface and route, the resolver, and the application you tested. Add the date, because a snapshot restore or a hypervisor update can change all four.
If IPv4 followed the tunnel, say that. Do not extend the claim to IPv6, another namespace or a different VM on a different network.