Wireshark shows the actual MAC address only for hosts on your local network segment because MAC addresses are Layer 2 delivery addresses that never cross a router. A router strips the incoming frame's Ethernet header, discards its source and destination MAC addresses, and builds a brand-new frame for the next hop. Whatever MAC you see on a remote packet belongs to your local gateway or the last router in the path, not the remote host.
The routing boundary explained
An Ethernet frame is a local delivery envelope, not an end-to-end container. The destination MAC address answers one question only: which network interface card on this wire should pick up the frame next? When a host sends to a remote address, it compares the destination IP against its own subnet mask.
If the IP falls outside the local subnet, the host does not attempt to resolve the remote IP to a MAC address at all. It addresses the frame to its default gateway's MAC instead. The IP header still carries the true remote source and destination, and those survive end to end. The MAC header does not, because each router along the path discards it and writes a fresh one.
This is why the Ethernet header is often called hop-by-hop while the IP header is end-to-end. The frame is rebuilt at every Layer 3 boundary. Your capture card sees frames on your own segment, so it sees only the MAC pair that matters for delivery on that segment. On a local exchange, that pair is the two real hosts. On an internet-bound exchange, one member of the pair is always a router interface.
Inside the frame rewrite
The mechanism is mechanical, and you can trace it packet by packet. A sending host builds a frame with its own NIC address as the source MAC and the gateway's address as the destination MAC. The gateway receives it, checks the frame check sequence, and strips the Ethernet header entirely. The IP packet is intact, with its original addresses and its time-to-live value decremented by one.
The router then consults its routing table, selects an outbound interface, and performs a new Address Resolution Protocol lookup on that interface. It writes a new Ethernet header using its outbound interface's MAC as the source and the next hop's MAC as the destination. The frame check sequence is recalculated because the frame contents changed.
Replace the MAC header and you must replace the checksum protecting it. That is a small but real reason routers cannot simply forward the original frame untouched. Some technologies do carry an original address inside the payload for other purposes. Proxy ARP, for instance, lets a router answer ARP requests on behalf of remote hosts, and the requesting host then stores the router's MAC as if it belonged to the target. Wireshark will faithfully display what is on the wire, which is the router's address, not the remote host's.
What a remote capture actually contains
Consider a capture taken while browsing a website on a server three hops away. The source MAC on incoming frames is your gateway's LAN interface. The destination MAC is your own NIC, or the switch port your machine reaches. The IP source is the web server, and the IP destination is your machine.
The same pattern repeats on every segment between you and the server. Each router's outbound frame carries that router's MAC, and no frame anywhere carries the server's NIC address unless the server and the client share a segment. A capture on the server side would show the server's MAC paired with its own upstream router.
Virtual local area networks and switches obey the same rule. A switch forwards frames within a VLAN based on destination MAC, so two hosts in different VLANs communicate only through a router, and each VLAN's capture shows only local MAC pairs. A host on the same VLAN as the target will show the target's real MAC in a capture, which makes VLAN topology the single biggest factor in what you see.
| Path type | Source MAC you see | Destination MAC you see | Remote host's real MAC visible |
|---|---|---|---|
| Same VLAN, no router | Sender's NIC | Receiver's NIC | Yes |
| Same physical LAN, different subnets | Sender's NIC or gateway | Gateway or receiver | Partly, via gateway frames |
| One routed hop (two subnets) | Local router interface | Local host or router | No |
| Internet, several hops | Your gateway | Your host or gateway | No |
| VPN tunnel endpoint | Physical NIC or tunnel pseudo-interface | Tunnel peer | No, inner frames show synthetic addresses |
| Container bridge on same host | Container veth address | Container veth address | Yes, within the bridge |
| Wi-Fi with client isolation | Access point address | Client address | No, even on the same subnet |
Quantified context and frame anatomy
The rewrite happens at every routed hop, and the number of hops is visible in the time-to-live field. A typical internet path crosses 8 to 15 routers, so the original Ethernet header is destroyed and rebuilt 8 to 15 times before arrival. The IPv4 time-to-live starts at values such as 64, 128, or 255 and decrements once per router, which is why it can shrink to the 50s or lower on distant paths.
Frame size also changes with the rewrite. Standard Ethernet frames carry up to 1,500 bytes of payload; jumbo frames on data-center links carry up to 9,000 bytes. When a WAN link uses a smaller maximum transmission unit, a router may fragment at Layer 3, and the resulting fragments share the original IP identification value. No fragment carries a remote MAC either, because each is re-encapsulated at the next hop.
The ARP cache on your machine is the practical source of local MAC truth. Entries typically expire after 60 seconds to a few minutes on modern operating systems, and each cache line pairs an IP address with a MAC and a state such as reachable or stale. The neighbor table on a router holds the same kind of mapping per interface.
One counterintuitive detail: the source MAC you see on an incoming frame may have been assigned by a switch or a virtual interface, not by the manufacturer of the remote hardware. Switch virtual interfaces, hypervisor bridges, and container network namespaces all present their own synthetic addresses. Treat every MAC as a claim about the local segment, never as proof of the ultimate sender.
Edge cases that break the simple rule
A few configurations make MAC addresses appear where you would not expect them, and each has a specific cause. Understanding them prevents misreading a capture.
Proxy ARP: a router answers for a remote IP, so the host caches the router's MAC while the IP still belongs to the remote host. Hubs and shared media: an old hub repeats every frame to every port, so a capture can see frames between other local hosts, but remote frames remain gateway addressed. Port mirroring: a switch mirror port carries a full copy of frames, which still show the gateway's MAC on routed flows. Captures on the router itself: a capture on both router interfaces shows the pre-rewrite frame on one interface and the post-rewrite frame on the other, revealing both address pairs. Anycast and load balancers: the destination MAC may belong to a virtual service address, while the IP belongs to the application. Virtual switches and tunnels: encapsulation adds an outer MAC header that points to the tunnel endpoint, and the inner header points to virtual interfaces that no physical NIC owns.
One more warning matters for analysts. A MAC address seen in a capture from the internet side is not a reliable identifier of the sending machine. Attackers and load-balancing appliances rewrite or randomize addresses, and modern privacy features randomize the MAC presented on Wi-Fi. Correlate with IP and timing instead.
Where Wireshark's display fits in
Wireshark does not alter anything; it displays the bytes the capture driver recorded. Two filters illustrate the boundary clearly. The filter eth.addr == aa:bb:cc:dd:ee:ff matches frames whose Ethernet header includes that address, and it will never match a remote host's NIC on a routed path. The filter ip.addr == 203.0.113.10 matches the remote host regardless of path because the IP header is preserved.
The same logic applies to name resolution. Wireshark may resolve a local MAC to a vendor name through its manufacturer database, and the vendor name reflects the gateway's hardware if that is the address on the wire. A resolved name never proves the packet came from that vendor's equipment end to end.
A professional caveat applies to timing as well. Because the frame check sequence is recomputed at each hop, corruption that occurs inside a router is invisible to your capture. You can only see integrity failures on your own segment. Deep path analysis requires captures at multiple points, not a single long trace.
Practical actions
If you need to establish the true MAC of a remote host, work the problem from the network topology outward.
Confirm the capture point. Record which interface, VLAN, and switch port the capture driver binds to, since the interface determines which segment you observe. Check whether the remote IP is inside the local subnet by comparing against the subnet mask. Same-subnet traffic should reveal the real MAC after ignoring stale ARP entries. Inspect your ARP cache with the operating system's neighbor command, and look at entries for the gateway and any same-subnet targets. Take simultaneous captures on the router or endpoint if you administer them, then compare the frame before and after the rewrite to see both address pairs. Use the IP header for identity and the MAC header for locality, and never treat a gateway's MAC as evidence about the remote machine. If wireless, verify that client isolation is disabled; with isolation enabled, remote peers behind the access point will show the access point's address instead.
Limitations and what a capture cannot prove
A capture proves what crossed one wire at one moment, nothing more. It cannot prove end-to-end routing, it cannot reveal a remote NIC's factory address, and it cannot certify the sender's identity through the Ethernet header. Broadcast captures on a switched network are equally partial because switches do not flood unicast frames.
The honest boundary is this: MAC addresses are a local addressing mechanism by design, so their absence for remote hosts is correct behavior, not a Wireshark defect. This article is general educational information about network protocols, not professional network-security or forensic advice; for incident-response or compliance questions, consult a qualified network security professional.