A Changed MAC Address on a Pi: Which Interface Changed?

After a VPN setup lands on a Pi, several interface identities may appear to have shifted. Yesterday's Ethernet address no longer matches today's list, and the conclusion writes itself: the VPN changed the MAC. Usually it did not. Comparing a physical uplink with a bridge or a virtual adapter is not a comparison, and the first job is to decide which object you are actually looking at.

Name the interface and the observer

Write down the device name, the interface type, the current link-layer address and the manager that owns it. Add the timestamp, because a display that changed at boot is a different event from one that changed when the tunnel came up.

Do this for the same interface before and after the connection event. Two observations of one object are evidence; one observation of two objects is a coincidence with a story attached. The difference is the whole investigation. Get the object wrong and every later measurement is wasted.

If a DHCP reservation is part of the problem, note which client identity the allocator actually received. A desktop list, a bridge identity and an old lease entry are three different records, and only one of them is what the router saw.

TUN, TAP and the uplink are different objects

The kernel draws a hard line between the two virtual types. TUN carries IP packets and has no Ethernet identity at all. TAP carries Ethernet frames and therefore does have one.

That means a TAP-side address is not the physical uplink's address, and a routed TUN address is not a replacement Wi-Fi MAC. They are different layers of the same machine.

A bridge is a third object. It has its own link-layer address, derived or configured independently of the ports attached to it, so a bridge coming up can change what a listing shows without touching any hardware. The ports keep their own addresses underneath it. Its address can also be set explicitly, in which case nothing about it derives from the hardware at all.

Who actually owns a real change

If the same physical interface genuinely changes address, look at the active connection profile before assigning a cause. Privacy settings, cloning settings and a recreated virtual device all produce that symptom without any VPN involvement.

Proximity in time is not causation. A tunnel starting and a profile being reapplied often happen in the same second because one triggered the other, and the address change belongs to the profile. Read the profile before you read the tunnel log.

Distinguish a recreated interface from an existing device as well. Persistent configuration and the runtime interface are related objects, and neither is a permanent hardware identity.

What a manager's cloning values mean

NetworkManager's Ethernet settings reference separates an explicitly assigned address from special values such as preserve, permanent, random and stable, with different spellings at the command line and the D-Bus interface.

Those values are a supported capability of one manager. They are not proof that this image runs that manager, that this profile used randomization, or that a VPN process rewrote a NIC. Only the active configuration on this host answers that.

Check the owner of the setting rather than installing a second manager to make the setting available. Two managers fighting over one interface produces exactly the instability people then blame on the tunnel.

Fix the identity requirement, not the display

Where a local reservation is needed, follow the allocator's own client-identity mechanism and make it agree with how the interface is configured. Pinning an unrelated bridge or tunnel address to keep a list looking stable solves nothing. It also creates a second identity nobody documented.

A remote routed VPN authenticates its own peer and assigns addresses through its own model. Freezing a LAN address does not enrol that peer and does not create a fixed tunnel assignment.

Before an approved identity change, keep the previous configuration recoverable, especially on a headless machine you cannot walk over to. Then verify the same interface and the same local service after a reconnect.

The finding worth writing down is which object changed, who configured it, and whether that violates the identity contract you intended. Anything broader is a guess wearing a conclusion's clothes. Narrow findings also survive review.