Hide Browsing on Hotel Wi-Fi (WireGuard VPNs)

A WireGuard VPN can encrypt traffic between your device and a VPN server while you use hotel Wi-Fi, limiting what the hotel network can read about your browsing. It does not make you anonymous or hide your VPN connection. Set up a full tunnel, handle the hotel sign-in page first, and test IPv4, IPv6, and DNS before relying on it.

Hotel Wi-Fi is convenient, but you do not control its router or network settings. A well-configured VPN can reduce the network’s view of your traffic without adding visible equipment or changing how you use your device. In most cases, setup means joining Wi-Fi, signing in, then switching on a trusted WireGuard profile.

I treat the word “connected” as a starting point, not proof that every connection is protected. A route for IPv6 or a DNS setting can behave differently from the main IPv4 tunnel. The practical goal is to check those paths and understand what the VPN does, and does not, conceal.

Plan the VPN and Threat Model

A threat model is a plain description of what you want to protect and from whom. On hotel Wi-Fi, the main goal is usually to keep the local network from reading traffic between your device and the VPN server. A VPN does not hide everything from the VPN provider, websites, or software on your device.

WireGuard sends IP packets through an encrypted tunnel over UDP. It uses the Noise_IK handshake and cryptographic tools including Curve25519, ChaCha20-Poly1305, BLAKE2s, and HKDF. Their specifications appear in RFC 7748, RFC 8439, RFC 7693, and RFC 5869. WireGuard itself is not an IETF RFC standard.

Before travel, get the profile and connection details from a VPN service or administrator you trust. A profile includes keys and settings that identify the peers. Do not copy a profile from an unknown source or share it; someone with access to its private key may be able to use that peer.

Ask for or confirm:

• The VPN server’s hostname or IP address and UDP port. Port 51820 is common, but WireGuard can use other ports.
• The client and server peer keys, supplied in the profile.
• Whether the client profile routes both IPv4 and IPv6.
• Which DNS resolver the tunnel should use.
• Whether your service has a supported firewall or kill-switch setting.

The VPN provider can see traffic that exits through its server, along with connection details. Websites can still identify you through account sign-ins, cookies, and other signals. A VPN is one layer of privacy, not a promise of anonymity.

Clear Captive-Portal and Network Access

A captive portal is a hotel sign-in page that appears before the network allows normal internet access. Complete that sign-in before turning on WireGuard. If the tunnel blocks the portal, disconnect it briefly, finish the hotel’s steps, then reconnect.

Join the hotel’s Wi-Fi using its stated terms and access code. Open a browser and wait for the sign-in page; if it does not appear, try the network’s login prompt or the hotel’s official instructions. Avoid entering sensitive details into a page that looks unrelated to the hotel or its network provider.

Once you have internet access, turn on the VPN. If a portal appears again later, temporarily disconnect the tunnel and complete the required sign-in. Then reconnect and verify the tunnel. Do not leave the VPN off simply because a portal appeared; reconnect when access is restored.

Hotel networks may restrict or block UDP traffic, which WireGuard needs. If the profile does not connect, confirm that the hotel network is working without the VPN, then ask your provider or administrator whether the configured endpoint and port are reachable. Some services offer another protocol for restrictive networks; use only a method they support.

Configure and Connect the WireGuard Tunnel

A full tunnel routes internet traffic through the VPN, rather than only traffic to selected work resources. In a WireGuard client profile, AllowedIPs = 0.0.0.0/0, ::/0 requests full-tunnel routing for IPv4 and IPv6. The client app, operating system, and server setup must all support the intended routes.

A simplified client profile may look like this:

[Interface]
PrivateKey = <your-private-key>
Address = <assigned-client-address>
DNS = <trusted-resolver-address>

[Peer]
PublicKey = <server-public-key>
Endpoint = <server-hostname-or-IP>:<configured-UDP-port>
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Use the actual values from your provider or administrator. Do not paste a private key into a public forum or a shared document. Some apps use menus rather than these exact fields, and the DNS option may be named differently.

AllowedIPs controls which destination addresses use the peer. If you include only 0.0.0.0/0, IPv4 traffic may use the tunnel while IPv6 traffic leaves over the hotel connection. Include ::/0 for IPv6 tunneling, then test it. If the VPN cannot carry IPv6, use a supported operating-system setting to disable IPv6 rather than assuming it is covered.

The DNS setting names the resolver used for domain lookups. A full-tunnel route alone does not prove DNS queries go through that resolver. DNS behavior depends on the app and operating system, so verify it after connecting.

PersistentKeepalive = 25 tells the client to send a small packet every 25 seconds. It can help a peer behind NAT stay reachable, but it is not needed for every connection. Use it when your provider or administrator recommends it, especially if the tunnel stops receiving traffic after a quiet period.

If your device offers a VPN firewall or kill switch, enable it if it fits your needs. Such controls aim to block traffic outside the tunnel when the VPN drops, but their behavior varies. Test the setting rather than assuming it prevents every leak on every network.

Verify Routing, DNS, and Leak Protection

Verification means checking actual routes and public network results, not relying only on a connected icon. Confirm the handshake, test both IP versions, and check DNS while the tunnel is active. Repeat after reconnecting, waking the device, or moving between access points.

First, check the WireGuard client for a recent handshake and increasing transfer counters. On Linux, wg show displays peer and transfer details. Other operating systems provide similar status in the WireGuard app. A handshake shows the peers have communicated; it does not prove all device traffic uses the tunnel.

On Linux, these commands can help inspect routes:

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

With full tunneling, the route lookup should point through the VPN interface or its routing policy. The exact output depends on the operating system and client, so use its network tools if these commands do not apply.

Next, use a reputable IP and DNS leak test while connected. The public IPv4 and IPv6 addresses should match the VPN’s egress, not the hotel connection. The DNS test should report the resolver you expect. A single “VPN connected” message or a successful IPv4 check does not confirm IPv6 or DNS protection.

Check	What to look for	If it does not match
Handshake and transfer	Recent handshake; counters change as you browse	Check endpoint, keys, UDP access, and profile
Public IPv4	VPN server’s public egress address	Check full-tunnel route and reconnect
Public IPv6	VPN egress, or no IPv6 if you have disabled it	Add ::/0 or use supported IPv6 controls
DNS resolver	Resolver set for the VPN	Review client DNS settings and test again
Sites loading	Pages load fully, not only partway	Check DNS, routes, and possible MTU issues

A common starting MTU is 1420 bytes on a path with a 1500-byte MTU. It is not a universal setting. If some sites stall or load only in part while the tunnel is active, path-MTU trouble is one possibility. Test changes with your provider’s guidance; do not assume lowering MTU is always the fix.

Worked Hotel Setups and Troubleshooting

These are illustrative setups, not reports of measured hotel networks. They show how I would test common situations without treating one successful connection as proof for every device or property.

Laptop with a sign-in page: Join the Wi-Fi, complete the portal, then enable the WireGuard profile. Check the handshake and test public IPv4, IPv6, and DNS. If the portal returns after a timeout, disconnect, sign in again, and repeat the checks.

Phone that reports connected but leaks IPv6: The profile routes IPv4, but its AllowedIPs omits ::/0. An IPv4 test shows the VPN address, while an IPv6 test shows the hotel connection. Add the IPv6 route if the service supports it, or disable IPv6 using supported device settings. Test again; do not infer coverage from the IPv4 result.

Tunnel connects, but pages stall: Confirm the handshake and try more than one site. Check DNS and routes before adjusting MTU. If the connection fails on hotel Wi-Fi but works on another network, UDP access may be restricted. Ask the provider about supported alternatives rather than changing ports at random.

These checks help separate a portal issue, routing gap, DNS issue, and possible path-MTU problem. Keep the profile current, and repeat tests after a major app or operating-system change.

What a Hotel Wi-Fi VPN Can and Cannot Hide

A WireGuard tunnel encrypts traffic between your device and the VPN server, which limits the hotel network’s ability to inspect destination traffic inside that tunnel. The hotel can still observe that your device connects to a VPN server, along with timing and traffic volume. The VPN provider may see traffic that exits its server.

The tunnel does not replace HTTPS, device updates, or endpoint security. It does not hide activity from destination services, device-management software, or malware on your device. If you use a work-managed device, follow your organization’s rules; its management tools may have visibility beyond the hotel network.

The practical next step is simple: prepare a trusted profile, sign in to hotel Wi-Fi first, enable full-tunnel IPv4 and IPv6, and verify routes and DNS. If a check fails, fix that specific gap before relying on the connection.

Frequently Asked Questions

Does WireGuard hide my browsing from a hotel?
It encrypts traffic between your device and the VPN server. The hotel can still see the VPN connection, its timing, and traffic volume.

Can the VPN provider see my browsing?
The provider may see traffic that exits through its server. A VPN shifts trust from the hotel network to the VPN provider; it does not remove the need to choose carefully.

Should I connect to Wi-Fi before starting WireGuard?
Yes. Join the network and complete its captive-portal sign-in first. Then connect the VPN.

Is port 51820 required?
No. It is a common default, not a required port. Use the UDP port configured by your VPN provider or administrator.

Does “connected” mean all traffic is protected?
No. Check IPv4, IPv6, DNS, and routing. A connection indicator alone does not prove full-tunnel coverage.

Why include ::/0 in AllowedIPs?
It routes IPv6 destinations through the tunnel. Without it, IPv6 traffic may use the hotel network outside an IPv4-only tunnel.

Does full-tunnel routing prevent DNS leaks?
Not by itself. Set a trusted tunnel DNS resolver and test which resolver handles queries while connected.

What does PersistentKeepalive = 25 do?
It sends a periodic packet that can help maintain reachability through NAT. It is optional and is useful only when the peer setup calls for it.

What if the hotel blocks WireGuard?
Ask your VPN provider or administrator about supported alternatives for restrictive networks. Do not assume changing a port will work or is allowed.

Does a VPN make me anonymous?
No. Websites, signed-in accounts, device software, and the VPN provider may still identify or observe activity in different ways.

(This article was written by one of our staff writers, Richard Montclair. Visit our Meet the Team page.)