Bringing a tunnel up does not make the local network forget the machine, although that is the usual assumption. Neighbour tables, leases and local name records say otherwise. The tunnel changes where your packets exit; it does not change what your neighbours can see.

Two views need checking. Neither of them is the hidden-or-not test most people run first.

Your Neighbours Still Know the Machine

A local address, a hardware address and, in most networks, a leased hostname all remain attached to the machine while it is connected. A router lists them, and on a flat segment other hosts can learn them too. Neighbour discovery, address assignment and local name resolution all happen on the segment rather than inside the tunnel, which is why a VPN does not suppress them. The frames carrying your traffic are encrypted end to end, while the lease and the neighbour entry were never part of that conversation.

What the tunnel hides is the destination list. Your router sees one encrypted flow to a single endpoint instead of a series of sites, though volume, timing and the endpoint's reputation still describe a good deal.

The Exit Address Is Only One Identity

The claim that a VPN hides a device on a local network is true in one narrow sense: a remote observer no longer learns your public address. That says nothing about the access point you are attached to, which still knows the hardware address it is talking to. Treating the two observations as one question is how people conclude a tunnel failed when it did exactly what a tunnel does. Separate them and each result becomes interpretable on its own.

Location has a second channel that never touches an address. Browser geolocation can be answered from a scan of nearby access points rather than from an address, because the operating system hands their identifiers to a lookup service that already maps them to places. Unplugging the radio removes that input; a different exit country does not.

If You Rent the Server, the Provider Sees the Pattern

Running the tunnel on a rented instance moves the observation rather than removing it. The hosting provider sees the source and destination of the outer flow because it has to route it, and the endpoint address identifies the service. Payload stays unreadable, but a host that talks to a single peer and to nothing else is not hard to classify. Nothing in that description requires breaking a cipher.

A pattern is not content. If the concern is the provider's records, the answer is a provider with a stated policy and a jurisdiction you accept, not a different cipher. A stronger cipher changes nothing about what the flow looks like from outside.

Split Tunnelling Decides Who Sees Your Queries

With a work tunnel, what the administrator can observe depends on the routes the client installs. With only the corporate prefixes in the tunnel, the gateway records exactly that slice of your traffic and nothing else. Without split tunnelling every packet goes through the employer, including domain lookups when their resolver is pushed to the client. That difference decides which of your habits the employer can observe at all.

Check the routing table instead of assuming, and note who answers a lookup for a public name. Once their resolver answers your lookups, they hold the query even when the page is fetched elsewhere.

Check Both Views Before Believing Either

Ask a second device on the same segment to resolve your hostname and print its neighbour table, then observe from outside which address a service reports. Those two answers describe different layers, and no single hidden-or-not check covers both.

arp -a
ip route show default
resolvectl status | head -n 20
dig +short example.com

Change one layer at a time when you test. Switch off the discovery protocol and the segment loses that view while the tunnel is untouched; switch exit country and a website's record changes while the segment does not.

Nsɛm a ɛfa ho