Enclave won't connect on a guest or visitor network¶

Staff who travel to other organisations' sites sometimes find that Enclave will not connect while they are there, even though it works everywhere else. This article explains why that happens, what can be done about it, and what to ask for when it is worth asking.

Symptoms¶

Enclave connects normally in the office, at home, and on a mobile connection, but will not come online while the device is on a particular visited network.
The problem follows the network rather than the device. Other staff on the same visited network see the same behaviour, and the device works again as soon as it moves to a different connection.
Connecting the device to a phone hotspot resolves it immediately.

Cause¶

Every network decides for itself what traffic is allowed to leave it. Enclave needs a small amount of outbound Internet access to reach the Enclave platform and to build its encrypted tunnels. Where the network being visited does not permit that traffic, Enclave cannot connect, and no change made on the Enclave platform or by the IT provider will alter that. The block sits on the host network, and only the host network can lift it.

Three firewall behaviours account for most of these cases.

Only web browsing is permitted¶

Many guest and visitor networks are built to allow staff and visitors to browse the web and little else. Enclave uses outbound TCP port 443, the same port a browser uses for HTTPS, but Enclave is not a website and its traffic does not look like web browsing. A firewall configured to recognise and permit only website traffic will drop it.

HTTPS inspection is enabled¶

Some firewalls decrypt, inspect and re-encrypt traffic on port 443 so they can examine its contents. Enclave's protocol on port 443 is not HTTPS and is not compatible with that inspection, so any connection subjected to it fails.

Traffic to the United Kingdom is blocked¶

Some firewalls geo-block: they refuse traffic to countries outside an approved list, judged by where each destination IP address is registered. The Enclave platform runs in Microsoft Azure's UK South region (see Security Practices), so a network that does not permit outbound traffic to the UK prevents Enclave from reaching it, even where every port and protocol Enclave uses is otherwise allowed. Geo-blocking is also a blunt instrument. It depends on third-party databases that map IP addresses to locations, and those databases are not always accurate, so an address can be blocked because it has been attributed to the wrong country.

Enclave does not route around geo-blocking, for example by presenting the platform through addresses that appear to be in another country. A block on traffic to the United Kingdom is a policy the network owner has chosen. An address that appears to be elsewhere, but still carries the traffic to the UK, would not satisfy that policy. It would only hide the traffic from it. Where the network owner is content for Enclave's traffic to flow, the right answer is an explicit exception for the Enclave destinations, as described under Resolution.

Other restrictions¶

Other network policies can have the same effect, including DNS filtering that blocks Enclave's domains and firewalls that restrict which outbound ports may be used. Enclave is present and reachable on the public Internet, but it cannot anticipate every restriction a network owner chooses to apply, and it does not try to evade them.

None of these behaviours is a fault, and none is aimed at Enclave. All are ordinary, defensible security choices. A network that permits only web browsing or inspects HTTPS traffic will usually block other remote access tools in the same way.

Resolution¶

The block sits on the host network, but the people affected by it rarely have any say over that network. A customer visiting another organisation's site cannot change its firewall, and usually just wants Enclave to work. Where the relationship allows it, the best outcome is to explain the cause to the network's owner so they can make an informed decision about permitting the traffic. Not every customer wants that conversation, or is in a position to have it, so the options below run from asking for a change to working around the network altogether.

Ask the site to permit the traffic¶

Where there is a working relationship with the site being visited, a short request to their IT contact is often all it takes. What Enclave asks for is narrow and specific: outbound access to a handful of destinations, no inbound ports, and nothing installed on their network. Most firewalls can accommodate it in a few minutes. The requirements are published in full at What firewall ports should I open to use Enclave?, which is the page to pass to whoever administers the network.

Something along these lines can be forwarded directly:

Our staff use Enclave (https://enclave.io) to reach systems securely while on site. Enclave needs a small amount of outbound network access permitted by the site firewalls. The destinations it uses have to be excluded from HTTPS/TLS inspection (Enclave's protocol is not HTTPS, so it cannot be inspected as if it were web traffic). The Enclave platform runs in Microsoft Azure's UK South region. If the site firewalls block traffic by country, these destinations also need an exception from that block. Exceptions based on hostnames are more reliable than ones based on IP addresses, because the IP addresses can change from time to time. No inbound ports are required and nothing needs to be installed on your network. The requirements are published here: https://docs.enclave.io/kb/firewall-ports/

Use an independent connection¶

A mobile hotspot or phone tethering bypasses the host network entirely and works reliably. It is the fastest answer when a site cannot or will not change its firewall, when the site is visited only occasionally, or when there is no IT contact to ask. For staff who regularly work from networks outside their employer's control, a data allowance for tethering is usually the most practical arrangement.

Plan around the sites that cannot change¶

Some networks will not be changed, whoever asks. Tightly regulated environments, larger organisations with centrally managed firewall policy, and venues running managed guest Wi-Fi will often decline, and that is their prerogative. Where a site is visited often enough to matter, it is worth identifying it in advance so staff travel knowing which connection they will be using, rather than discovering the problem on arrival.

Summary¶

The constraint here is not a defect in Enclave and is not something the IT provider can configure away. A visited network controls what leaves it, and where its policy permits only web browsing, inspects HTTPS traffic, or blocks traffic to the United Kingdom, Enclave will not connect from it. The realistic choices are to ask that network to permit a short, specific list of outbound destinations, or to use a connection that is not subject to its policy.

Having problems? Contact us at support@enclave.io or visit our support options.

Last updated September 22, 2026