WireGuard Roaming Explained: Moving Between Networks

Anyone who uses a VPN on a phone knows the moment. You walk out of a cafe, the phone drops Wi-Fi and picks up mobile data, and you hope the tunnel survives. With some protocols the connection collapses and you wait while the app reconnects. WireGuard was designed so that this kind of move is normal: its roaming behaviour lets the tunnel carry on after your device changes address, often without any visible interruption.

This article explains what wireguard roaming actually does at the packet level, why it works, which parts depend on you or your VPN app, and what can still go wrong. It is protocol education rather than a setup guide. It also does not claim anything about which protocols a particular provider offers. For the broader comparison with older designs, see WireGuard vs OpenVPN.

The problem roaming solves

Every internet connection is described by addresses and ports. A traditional VPN session is often tied to the pair of addresses that created it. When your phone changes network, its public address changes too, and the old session no longer matches anything the server recognises. The server drops the packets, the client waits for a timeout and then negotiates everything from scratch.

Moving between networks is common:

• A commuter switches from home Wi-Fi to mobile data on the way to the station.
• A laptop user closes the lid at the office and opens it at a cafe.
• A traveller's phone hops between hotel, airport and mobile networks in the same afternoon.
• A home connection renews its address after a router restart.

If a tunnel needs a visible reconnect every time, the VPN becomes an annoyance and people turn it off. Roaming is the design answer to that.

How WireGuard roaming works

WireGuard does not keep a session tied to an address. Each peer is identified by its public key, and the configuration says which internal addresses that key may use. The external IP address and UDP port of a peer, called its endpoint, are treated as a hint that can change.

The rule is short:

1. A peer sends encrypted packets to the last known endpoint of the other peer.
2. When a packet arrives, the receiver checks that it is authentic using its session keys.
3. If the packet is valid and its source address differs from the stored endpoint, the receiver updates the endpoint to the new source.
4. The next reply goes to the new address.

That is all. There is no separate roaming message and no negotiation. The first genuine packet from the new network re-teaches the other side where you are. The whitepaper listed in the references describes this behaviour and the cryptographic design behind it.

Why this is safe

An attacker who copies one of your packets and replays it from a different address does not gain control of the tunnel. The packet either fails authentication, or it is a repeat that the protocol's replay protection discards. The endpoint changes only for packets that prove knowledge of the session keys, which only the two real peers hold.

Which side can roam

Roaming works best when one side has a stable, reachable address and the other moves. That is the usual shape of a VPN: the gateway stays put, and your phone or laptop travels.

Situation	Does it work?	Why
Phone roams, gateway has a fixed address	Yes	The phone sends a packet; the gateway learns the new endpoint
Gateway keeps its address but the phone is behind NAT	Yes, with keepalives	The phone's outbound packets keep the NAT mapping open
Gateway changes address, phone does not	Depends	The phone keeps sending to the old address until its configuration is re-resolved
Both sides change address at the same moment	Often not	Neither knows where to send the first packet
Two peers behind separate NATs, no relay	Needs help	Neither can be reached first, see below

The last two rows are typical of peer-to-peer meshes rather than a phone connecting to a gateway. For how those designs cope, read the explanation of VPNs behind CGNAT.

Keepalives and the NAT problem

There is a catch. Roaming depends on a packet arriving from the new address. If your device is quiet, it sends nothing, and the gateway has no reason to learn about the change. Worse, many home routers and mobile networks forget their NAT mappings after tens of seconds of silence, so inbound packets from the gateway stop arriving even though nothing has been disconnected.

WireGuard offers an optional setting called persistent keepalive. When enabled with a small interval, such as 25 seconds, the peer sends an empty authenticated packet even when it has nothing to say. This does two jobs:

• It keeps the NAT mapping on the path alive.
• It tells the other side the device's current endpoint within a few seconds of any change.

The cost is a small trickle of traffic and a little battery. For a phone used all day, that trade is usually reasonable, and many apps pick a sensible value for you. For a stable desktop on a wired connection, no keepalive may be needed. If you want to understand the battery side, see does a VPN drain battery.

Rekeying and handshakes during a move

WireGuard also refreshes its session keys on a timer, roughly every couple of minutes when traffic is flowing, using a short handshake. Roaming and rekeying are separate mechanisms, but they interact in a useful way: the handshake packets themselves also update the endpoint. If your phone changes network and sends a handshake from the new address, the gateway learns the move at once.

A short example of the timeline:

1. 09:00:00: Your phone is on Wi-Fi with an active tunnel.
2. 09:00:10: You leave the building, and the phone switches to mobile data with a new address.
3. 09:00:11: The app sends a packet. The gateway authenticates it and updates your endpoint.
4. 09:00:11 onward: Replies come to the new address. Pages that were mid-load may stall briefly and then continue.

If step 3 needs to wait for you to do something, such as open an app, that delay is what you perceive as the tunnel being "stuck".

Why a tunnel still stalls after roaming

Roaming is not magic. These are the usual reasons for a stall, in the order worth checking.

1. The new network blocks UDP. WireGuard uses UDP. Some hotels, offices and public networks filter it, so packets from the new address never arrive. Move to mobile data or another network to confirm.
2. A stale NAT mapping. The old path lingers until it expires, and replies go nowhere. A keepalive usually avoids this.
3. The endpoint name was resolved once. If the gateway is configured by hostname and its address changes, the client may keep using the old one. Apps that re-resolve the name on reconnect handle this; some need a restart.
4. The operating system paused the app. Aggressive power saving can put a VPN process to sleep right at the moment of the switch.
5. A captive portal. A new Wi-Fi may demand a sign-in page before any traffic passes. The VPN cannot get through until that is done. See VPN captive portal issues.
6. Packet size. The new network may have a smaller maximum packet size, and large packets vanish. VPN MTU problems explains the symptom.

If you hit a stall, the quick steps in reconnecting when the VPN disconnects cover toggling the connection cleanly, and improving VPN connection stability goes further.

Roaming compared with other protocols

Other protocols solve the same problem in their own way. IKEv2 with the MOBIKE extension can also update addresses without rebuilding the whole session, which is why it has a good reputation on phones; the details are in WireGuard vs IKEv2. OpenVPN in its common modes often has to re-establish the session after an address change, which is why a delay is more noticeable. These are general design differences, and the results you see also depend on the app and the operating system.

A simple way to test roaming yourself

You do not need special tools to see how your own device behaves. Try this on a phone you already use with a VPN app.

1. Connect the VPN on home Wi-Fi and confirm that pages load.
2. Start something continuous but harmless, such as a long audio stream or a ping test app.
3. Turn Wi-Fi off from the quick settings, so the phone moves to mobile data. Note the time.
4. Watch how long the stream pauses. A pause of a few seconds is a good result; a pause of half a minute or more suggests the app is waiting for a timeout or a handshake.
5. Turn Wi-Fi back on and repeat. Moving back often behaves differently from moving out, because the phone may take a moment to prefer Wi-Fi.
6. Repeat once on a different network, such as a cafe, because a network that filters UDP changes the result completely.

Write down what you see. If the pauses are long on every network, look at the app's battery and background settings before blaming the protocol. If they are long only on one network, the problem is probably that network. This kind of observation is more useful than any rule of thumb, because the outcome depends on your phone, its operating system and the VPN app together. Do the same with a laptop by switching from Wi-Fi to a phone hotspot, which is also a good test of what happens to long-running downloads.

What roaming does not do

• It does not fix a bad network. If the new connection is slow or congested, the tunnel will be too.
• It does not hide that you moved. The gateway learns your new address as part of normal operation. Your network operator sees the changes as well.
• It does not guarantee every app survives. Individual downloads, calls and game sessions may still drop because the app, not the tunnel, loses its connection.
• It is not a privacy feature in itself. It makes the tunnel more convenient. Privacy depends on the operator, your settings and your habits.

Summary

WireGuard roaming works because peers are identified by cryptographic keys, not by addresses. When an authenticated packet arrives from a new address, the receiving side updates the stored endpoint and replies there, without a separate negotiation. A keepalive helps devices behind NAT stay reachable, and most stalls come from blocked UDP, stale mappings, hostnames resolved once or captive portals. Test your own device by switching networks while a tunnel is active, and use the stability guides if it hangs.

If you want to try a VPN app on your own phone and laptop, the download page lists the free app, and the pricing page explains how a prepaid pass works.