Remote employees keep DNS protection while traveling when policy follows the managed endpoint instead of relying only on office DNS. Give travelers a captive-portal sequence, verify the active resolver after joining hotel Wi-Fi, test required work services, and document VPN or browser-DNS interactions. Keep a time-limited recovery route for networks that prevent the normal connection.
Design for the hotel connection sequence
Hotel access has two separate stages: joining the local network and satisfying its captive portal before ordinary internet access begins. Modern portal standards describe a client learning that it is captive, retrieving a portal address, and checking again after the user completes the portal. Protected DNS or a VPN can therefore be healthy while the network is still captive. Treat portal completion as a connection state, not proof that endpoint policy failed.2
Write the expected order before anyone travels: confirm the hotel network name with staff, join it, complete the portal, and then confirm the protected DNS and VPN paths in the order your team has tested. Never tell a traveler to accept a certificate warning. The captive-portal standard requires an HTTPS portal and valid server authentication; an unexpected certificate or a request for company credentials belongs in the stop-and-call branch.2
| Observation | Likely boundary | Next check |
|---|---|---|
| Wi-Fi joins but no portal appears | Portal detection or protected resolver interaction | Pause VPN as documented and trigger the portal |
| Portal completes but work domains fail | DNS policy, browser resolver, or VPN path | Run resolver test and test one required service |
| All sites fail after VPN starts | VPN transport or hotel restriction | Use approved hotspot fallback or contact support |
| One service fails | Service dependency or narrow policy result | Capture exact hostname and policy outcome |
Prepare a traveler support card
- Update the managed endpoint, browser, VPN client, and security tools before departure.
- Record how the endpoint normally gets DNS and whether the browser or VPN can select another resolver.
- Test office Wi-Fi, home Wi-Fi, and a phone hotspot so the traveler recognizes a healthy result.
- List the portal sequence, provider-supplied resolver test, support contact, and approved hotspot fallback.
- Name essential services to test after connection, including authentication and conferencing.
- Define any temporary exception by exact scope, owner, expiry, and restoration test.
Keep the card short enough to use from a phone while the laptop is offline. Include screenshots only when they match the managed platform version; stale screenshots create more confusion than plain labels. Avoid a generic instruction to “turn off DNS” or “try another resolver.” That erases the evidence support needs and can leave the endpoint unprotected for the rest of the trip.
Verify protection from the room
After the portal succeeds, run the DNS provider’s harmless test from the endpoint. Confirm that the expected resolver and policy identity appear, then test one known policy outcome and each essential work workflow. Check with the VPN both on and off only when policy permits; a VPN may own DNS while connected. Managed browsers can also choose a secure-DNS path distinct from the operating system, so record the browser state rather than assuming every application follows one resolver.56
A DNS test proves only the lookup path and response. DNS filtering can act on domain requests and policy outcomes, but cannot read page contents, search terms, in-app chats, voice audio, or full browser history. It does not prove that TLS is sound, a device is malware-free, or all application traffic is protected. Use endpoint, identity, browser, and VPN controls for those separate jobs.
Diagnose without collecting a travel diary
Start with state, not detailed activity: device label, time, network joined, portal completed, expected resolver result, VPN state, browser, and failing work service. Compare aggregate success or failure metrics before opening retained requests. If a narrow activity review is necessary, tell the traveler why, limit it to the incident window, and restrict access to the people handling the case.
- Do not ask staff to send hotel passwords, room numbers, or unrelated browser history.
- Do not create a permanent travel bypass because one portal behaved badly.
- Do not assume a successful DNS lookup means an application completed its connection.
- Do not blame the traveler for an undocumented resolver, VPN, or portal interaction.
- Do not close the case until normal protection is restored and verified.
End the case with a useful record: hotel or network type without unnecessary personal detail, device and software versions, failing stage, recovery used, final resolver result, and any runbook change. Protective DNS can follow roaming devices, but that continuity still depends on the endpoint using the intended path.3 Repeated failures should improve the support sequence, not justify broader surveillance or weaker policy for every traveler. Review the card after each incident so the next person gets a tested sequence rather than improvised troubleshooting.
Hotel Wi-Fi support questions
Should travelers disable protected DNS to open a hotel sign-in page?
Not as the first step. Join the network, open a plain HTTP page if the hotel instructs users to trigger its portal, complete the portal, and then verify the protected resolver. If a temporary change is necessary, use the documented recovery procedure and restore protection immediately afterward.
Does endpoint DNS make hotel Wi-Fi safe?
No. It can preserve domain-level policy and encrypted DNS transport where configured, but it does not make an untrusted network trustworthy. Teams still need HTTPS, updates, endpoint protection, strong authentication, and an appropriate VPN for traffic protection.
What evidence should a support request include?
Ask for the device label, time, network state, resolver test result, VPN state, browser used, and the exact work service that fails. Avoid requesting a broad browsing history or screenshots containing unrelated personal activity.
Apply the travel workflow in Veilty
In Veilty, keep roaming work devices in the relevant Tenant. Assign reusable baseline and enforced policies to that Tenant: resources added within it may override the baseline, while enforced policy takes precedence and cannot be weakened. Test one endpoint through a captive portal and hotspot, and keep travel exceptions narrow and temporary. Invitations add people to the account; after acceptance, Tenant roles grant access to the Tenant. Retained activity belongs to that Tenant, is end-to-end encrypted, and is visible only through permitted roles, while the resolver still processes live requests to answer them. BYOD controls are planned for Enterprise, so do not present employee-owned travel devices as a current managed workflow.1