Why Hotel and Office Wi-Fi Break Device-to-Device Transfer

By ShareDrop.org Engineering · Published 2026-09-03

Two phones on the same hotel Wi-Fi, a metre apart, and neither AirDrop, Quick Share nor LocalSend can see the other. Nothing is broken. Managed networks are configured to stop exactly this, for reasons that are good for the hotel and bad for you. Here are the four mechanisms, how to recognise which one you are hitting, and what still works.

1. Client isolation: devices cannot see each other at all

Also called AP isolation or guest isolation. The access point refuses to forward traffic between two wireless clients: every device can reach the internet and nothing else. It is the default on hotel, airport and café networks and on most “guest” SSIDs at offices, because it stops one guest's malware from probing another guest's laptop.

How to recognise it: nearby-share tools show no devices; a transfer tool that can use a relay reports Encrypted relay even though both devices are on the same network. Effect: any LAN-only method is dead. Anything that can go out to the internet and back still works, slowly, via the venue's shared uplink.

2. Captive portals: you are not really online yet

The page that asks for your room number or an email address intercepts all traffic until you accept. Devices that joined the network but have not completed the portal are in a walled garden: they can reach the portal and nothing else. A phone that auto-joined while in your pocket is often in this state.

How to recognise it: apps load nothing; a browser opened to any site redirects to the venue page. Fix: open a browser and complete the portal on both devices: the one that seems connected may not be.

3. Blocked multicast: discovery is silent

AirDrop, Quick Share, LocalSend, printers and smart TVs all find each other by shouting on the network — multicast DNS and similar broadcast protocols. Enterprise access points commonly drop multicast to save airtime, and some drop Bluetooth-adjacent discovery too. The devices can talk if they knew each other's address; they just cannot learn it.

How to recognise it: the network is not isolated (you can ping the other device if you find its IP), but discovery lists stay empty. Effect: tools that use a rendezvous server to introduce devices (a QR code or a short code instead of local discovery) are unaffected, because the introduction happens over the internet, not by shouting.

4. Symmetric NAT and UDP blocking: no direct path even via the internet

Corporate networks often put every device behind a symmetric NAT (what that means) and some block UDP outright, allowing only web traffic on ports 80 and 443. Peer-to-peer connections that would normally punch through a home router cannot; the tool must fall back to a relay, and if UDP is blocked, to a relay over TCP or TLS on port 443.

How to recognise it: the transfer connects but reports a relay even though neither device is on a guest network; or it fails to connect at all on a locked network. Effect: throughput is bounded by the venue uplink; if the network blocks even TLS to unfamiliar hosts, nothing short of a VPN will work.

Diagnosing it in two minutes

1. Portal first. Open a browser on both devices and load any site. If either redirects to a login page, complete it; a device that auto-joined in a pocket is often stuck here.
2. Read the badge. Start the transfer. LAN direct means the network is fine. Encrypted relay between two devices in the same room means client isolation or blocked multicast; Internet direct in the same room means multicast is blocked but the router lets devices reach each other through its public side.
3. The hotspot test. Put both devices on one phone's hotspot and retry. If it now says LAN direct, the venue's network was the cause and the hotspot is your workaround for the day.
4. If nothing connects even on the relay, the network blocks unknown destinations outright, cause 4 in its strictest form, and only the hotspot, a cable or a cloud upload will work.

Airports, planes and trains

Airport Wi-Fi is the hotel case with more users: isolation, a portal, and a shared uplink under heavy load. In-flight Wi-Fi adds two problems of its own (satellite latency of half a second or more, and a habit of blocking UDP entirely), so a transfer that connects at all will run over the relay on TCP at a few hundred kilobytes per second. Train Wi-Fi sits between the two. On all three, a phone hotspot is not available in the air and is the right answer on the ground; and on all three, a cable between phone and laptop ignores the network completely.

The guest network in your own house

Many home routers enable client isolation on their guest network by default, because that is what a guest network is for. A visitor's phone on the guest SSID and your laptop on the main one cannot see each other, and neither can two guests. If a transfer between two devices at home relays instead of going direct, check that both are on the same SSID, the main one, rather than one on guest. Mesh systems sometimes add a second layer: a device on a satellite node with isolation on is invisible to the rest of the house.

Corporate laptops: the network that travels with you

A work laptop with an always-on VPN carries the office firewall wherever it goes: at home, in a café, on a hotspot, its traffic still exits through the company gateway with the company's UDP block and bandwidth caps. The symptoms look like a hostile venue but follow the laptop, and the hotspot test does not change them. The fix is the VPN's split-tunnel setting if policy allows it, or accepting the relay over TCP if not (the VPN cases in detail).

If you can talk to whoever runs the network

The request that makes direct transfers work is small: allow outbound UDP to port 3478, which is the same traffic video calls need, and (for two devices on the same network to see each other) do not isolate clients on the SSID they share. Nothing inbound, no port forwarding. Guest networks will keep isolation on, and rightly so; a staff or private SSID usually does not have it, and asking to be put on that one is often the whole solution.

The portal that never appears

A laptop joins the hotel network, the login page never opens, and nothing works. The cause is that modern browsers load HTTPS sites, which a captive portal cannot redirect without triggering a certificate warning — so it silently fails instead. Type a plain HTTP address such as http://captive.apple.com or http://neverssl.com into the browser; the portal can intercept that, and the login page appears. Phones detect portals automatically; laptops often need this nudge.

What still works, ranked

1. Your phone's hotspot. The single most reliable fix. Turn on Personal Hotspot, join the laptop (or the other phone) to it, and both devices are on a private network you control: no isolation, no portal, no multicast filtering. Nearby share tools work again, and a P2P transfer shows LAN direct.
2. A transfer tool with a relay fallback. When client isolation blocks the LAN path, a tool that can route through an encrypted relay still completes the transfer over the venue's internet connection. It is slower than LAN, bounded by the shared uplink, but it works, and a good tool tells you it is relaying (what the relay can and cannot see).
3. A cable. Immune to every network policy. Phone-to-laptop over USB is often the fastest option in a hotel anyway.
4. Cloud upload. Works whenever the internet does, at the cost of a round trip through someone's servers and a stored copy.

Why venues do this

It is not spite. Client isolation prevents a compromised laptop from attacking the other 300 guests; dropping multicast keeps a busy access point from spending its airtime on discovery chatter from a hundred devices; symmetric NAT and UDP blocking are the cheapest way for a corporate firewall to enforce “web only.” The policies are reasonable for a shared network. They are simply built for a world where devices talk to servers, not to each other, which is why the reliable answer is to make your own small network with a hotspot.

Specifications referenced

• RFC 6762: Multicast DNS, the link-local discovery that client isolation and multicast filtering silence.
• RFC 8952: Captive Portal Architecture, how a network is supposed to signal that a sign-in page stands between you and the internet.
• RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements, the mechanism that lets a device find the portal without guessing.
• RFC 4787: NAT Behavioral Requirements for Unicast UDP, including the address-dependent mapping informally called symmetric NAT.
• RFC 8656: Traversal Using Relays around NAT (TURN), the relay that still works over TCP and TLS on port 443.