Monero over VPN: which of the three network paths changes?

Open the wallet, start the daemon and draw three arrows before you enable anything. One arrow runs from the wallet to a node's RPC port, one carries the daemon's peer synchronization, and one carries locally submitted transactions toward a relay path. They are different connections with different configuration, and a VPN or anonymity network may cover one, two or none of them.

Walk the paths in the order the software opens them. Labeling each arrow with its destination and transport is what makes the later privacy claim testable. The order matters, because a later claim usually covers only one of them.

Start by drawing the wallet-to-node connection

A wallet that talks to a remote node sends RPC requests to that node's address and port. A wallet with a local daemon talks to the loopback interface instead. Those are different trust relationships even though both are called "the node" in casual conversation.

Write down the address, the port and the transport the wallet is configured to use. If the wallet has its own proxy setting, record it separately from the daemon's settings; configuring one process does not configure the other.

This is also where a public RPC endpoint becomes tempting. Exposing the node's RPC service to simplify the diagram trades a network path for an attack surface. Keep the wallet-to-node link on a private path or the loopback interface, and document which one it is. A diagram that hides that exposure is worse than no diagram.

Next, follow the daemon's peer traffic

A synchronizing daemon opens outbound connections to peers and exchanges chain data over its peer-to-peer port. That traffic is not the wallet RPC link, and it is not automatically routed through a wallet's proxy. It follows the daemon's own network settings and the host's routing table.

Record the peer port, the number of connections and whether the daemon is configured to use a proxy for peer traffic. Then check the host route for a sample peer address. If the VPN captures the default route, the peer connections probably use it; if the daemon is bound to a specific interface, they may not. Those two facts decide the arrow.

The observer question changes with this path. A VPN hides the peer connections from the local access network, but the VPN endpoint and the peers themselves see a different view. Neither observation proves that the wallet's requests took the same route.

Then isolate the transaction relay path

Locally submitted transactions can be forwarded toward the network through a configured relay or proxy. In current Monero daemon documentation, that option sends only the transaction-relay traffic you point at the proxy. It does not turn every RPC, wallet and synchronization connection into proxied traffic.

The project's anonymity-networks documentation describes Tor and I2P integration as experimental and scopes the relay behavior. Read the documentation for the version you actually run, because older discussions use names such as Kovri and describe components that no longer exist in the same form.

Keep the relay path separate in the diagram. A transaction that leaves through a proxy while the wallet's balance queries use a remote node has two different observers, and the fact that the transaction was proxied says nothing about the query path.

Add the VPN only after the three paths are labeled

With the arrows drawn, mark which ones the VPN actually carries. A full-tunnel VPN captures the host's default route, so connections that follow the default will use it. A split tunnel, a bound interface or a proxy that connects out through a specific address can leave some arrows outside the tunnel.

Now state the observer model explicitly. Under a design where an anonymity-network connection runs inside the VPN, the local access network sees the outer VPN connection, while the VPN side sees the onward connection. That is a change of observer, not proof that identifying signals disappear.

Check the failure behavior as part of the same walkthrough. If the VPN drops, does the daemon fall back to a direct peer connection, does the wallet keep polling the remote node, and does the relay proxy fail closed? Unless blocking is configured, a reconnect usually means a new direct attempt rather than silence.

Verify the paths you think you configured

Use the host's own tools: read the route for each destination, inspect the listening and established sockets, and confirm which process owns each connection. Do this while the wallet, daemon and relay are all running, because a path that exists only at startup can disappear after a reconnect.

Repeat after a VPN reconnect and after a daemon restart. Compare the destinations and the transports with the diagram. If an arrow moved, the privacy model moved with it, even if every process still reports healthy.

Record the three destinations, the transport for each and the observer you intend to hide them from. A short path map with named observers is more useful than a single VPN indicator when several independent clients are running on one machine.