Taking a work VPN to the UAE: what to confirm first

Start a work trip from a narrower question than whether VPN software is allowed in general. The useful one is which private system you need to reach, through which company gateway, and who supports the device if the tunnel will not come up. Everything else about connectivity is a second conversation, and mixing the two produces a plan that answers neither. A written plan separates them.

What the documented use case actually covers

The UAE telecom regulator, TDRA, publishes Internet Guidelines that address organizational use of VPN technology for reaching internal networks, alongside separate discussion of content filtering and communications services. Those are distinct subjects. A company reaching its own intranet through its own gateway is a described organizational use case, not a blanket statement about every service a traveller might use. Nor is it a legal opinion about your particular trip, and reading it as either one is where most arguments about this subject start.

Read the published guidance directly rather than a summary, and treat this page as a planning checklist rather than as advice on your legal position. For anything outside the documented internal-access case, the questions belong to qualified local counsel and to your employer's travel policy.

Map the work to a specific gateway

Write down the systems you actually need: the intranet, a document store, the internal application that does not exist outside the company network. Then put two questions to IT: which approved gateway serves those systems, and whether the travel profile alters anything else about the device. The answer is usually more specific than the profile name suggests.

Some organizations publish a dedicated travel gateway with a different certificate or a different authentication step; others expect you to use the ordinary profile, which may route all traffic rather than only corporate ranges. The profile name rarely tells you which. Ask, or read the routing table once you are connected.

Knowing which one you have changes what you should expect. A full-tunnel profile sends your ordinary browsing through the company as well, which may be exactly what the employer intends and is certainly something to understand before the trip rather than during it. It also identifies the support path, because the person who can reissue a certificate or reset an account is usually reachable during business hours in one time zone. That matters more than the client version.

What the profile does to the rest of your traffic

A split-tunnel profile carries only the corporate prefixes; a full-tunnel profile carries everything. Neither is inherently better, but only one of them matches the narrow internal-access use case, and the difference is a configuration decision your organization has already made. You can read the result on the device rather than guessing from the profile name:

ip -4 route
ip -4 route get 10.20.4.10
nmcli connection show --active

The second command shows which interface would carry traffic to a corporate address. If your ordinary destinations also resolve through the tunnel, the profile is full-tunnel, and any expectation that ordinary browsing stays outside it is wrong. Better to discover that before the trip than during a call.

DNS follows the same logic. A resolver pushed by the tunnel decides where names go, and a split configuration can send internal names to the company and everything else to the local resolver, or the reverse depending on how it was built. Check which resolver the device is actually using after you connect, not which one the profile promised. A lookup of an internal name from a hotel network is the fastest way to see the difference.

Prepare the failure path before you fly

Assume the tunnel will not connect on the first attempt from a hotel network, and decide in advance what you will do. That means the approved fallback your IT team supports, the contact who can help across time zones, and the local number for the device if authentication depends on a phone. Writing those three down is the difference between a plan and an intention.

Test the supported authentication and recovery steps before travel, including any second factor that requires an enrolled device. A factor that needs a roaming number you have not activated is a failure you can predict today and cannot fix at the airport. Test the fallback too, not only the primary path, and do it from a network that is not your office LAN. A fallback nobody has tried is a hope rather than a plan.

Keep the fallback inside the organization's approved options. An improvised public exit is not a support path, and it is not a decision to make alone in a hotel room. If the approved fallback also fails, the correct next step is the support contact, not a different exit.

Keep the record and recheck it

Save the plan where you will find it: the gateway name, the supported contact, the systems you needed, and the date you checked the regulator's guidance. Guidance and organizational policy change, and a note with a date is worth more than a memory. It also makes the next trip cheaper to plan.

Then review the plan for the parts that are not about technology at all — what you will do if a service you expected is unavailable, and who decides whether the trip proceeds. Those answers are usually held by a person, not by a client setting.