No Inbound Peers on Your Bitcoin Node Behind a VPN?

Your node is synced, the VPN says connected, and getpeerinfo shows eight or ten peers. None of them has inbound set to true. That combination is normal and it is not a fault: outbound connections prove the node can reach others, and nothing about them proves anyone can reach you. If the goal is a node that accepts incoming P2P connections through a VPN, you have to test that direction on its own.

Follow the packet from the peer to your listener

Inbound P2P is a chain of four things, and it fails at the weakest link rather than the most interesting one.

other peer
  -> provider's public address and assigned port
  -> the permitted VPN mapping
  -> Bitcoin Core's P2P listener

Core's mainnet P2P default is 8333, but the provider can hand you a different public port and a different client-side destination. Write down the public address, the external port and where the provider actually delivers the traffic. Then confirm your plan and account permit incoming connections at all, because a dedicated exit address is not a port-forwarding contract.

That distinction catches people who buy a static IP expecting reachability. The address being stable says nothing about whether the provider forwards an inbound port to your session.

Check the listener before you check the provider

Core has to be listening on the address and port the mapping delivers to, and the host firewall has to permit it. If the node runs in a container or on another LAN machine, the onward hop and its reply route belong in the chain too.

A local firewall rule cannot create a mapping at a provider that drops incoming packets, and a provider mapping cannot reach a process that is bound only to loopback. Both halves have to agree on the same tuple, which is why the first step is writing the tuple down rather than guessing at it.

Keep the advertised endpoint consistent with the live mapping. A static address does not make an assigned port or its lease permanent across reconnects, so an endpoint published months ago may now point at nothing. Re-read the provider's page after any reconnect and compare it with what your node advertises. If the port moved, the old endpoint is now either nobody's or somebody else's.

Read the inbound flag, not the connection total

From an authorized local RPC context, this read-only query lists peers:

bitcoin-cli getpeerinfo

The RPC reference defines inbound as true for an incoming connection and false for an outgoing one. Look at that field. A total above ten proves nothing about direction, and the totals and categories shift with configuration and release anyway.

Then test the mapped endpoint from outside with a fresh reachability check you are authorized to run, and see whether a corresponding inbound peer appears. Be careful with the output you paste into a support thread: peer addresses are other people's connection details, and they do not need to be published for your question to be answered.

Do not solve it by exposing RPC

Bitcoin Core's RPC documentation explicitly warns against exposing the RPC interface to the public internet. Peer connections and authenticated administration are different services, and making P2P reachable by publishing RPC trades a connectivity problem for a much worse one.

If you would rather not depend on inbound P2P at all, an onion service is the documented alternative, and it has its own prerequisites: Tor available, control authentication configured and listening settings that allow the service to be created. It does not appear because a VPN happens to be running.

Excluding Core from the VPN is a third design, and a legitimate one for some operators, but it puts peer traffic on your ordinary connection. That is not inbound access through the VPN, and a router or upstream NAT may still need its own permitted entry. Pick which of the three you are actually testing before you change anything else.