Secure enclave is designed to work in BYOD/unmanaged environments, enterprise environments and education environments. All of these are configured differently and will require tuning to make sure network traffic is routing properly and optimally. You can use this guide to make sure your company’s Private Company Gateway, PCG for short and our APIs must be accessible and network traffic is routed effectively and optimally.

In an BYOD/unmanaged environment many end users use 3rd party VPN services and consumer security products (e.g. Avast One, ESET home security) that may have features that will need to be configured to allow for optimal operation of the secure enclave private company gateway.

In an enterprise setting it is typical to see a network and security stack that requires configuration in order for Secure Enclave connectivity to work in an optimal way.  The below diagram give you a high level overview of how the environment should be configured.  You can click the below diagram to zoom in.

Network Requirements

The following network requirements must be implemented within the environment in order to achieve optimal connectivity and performance:

1. Endpoint firewalls (e.g. Windows Firewall, Tanium) must be configured to allow traffic from the secure enclave apps (see Windows endpoint firewall rules below).
2. Endpoint DNS and web filtering software (e.g. Bluecoat, Umbrella) must be configured to allow secure enclave traffic (based on bypass table below).
3. Endpoint proxies, web gateways, SASE products, DLP and wan acceleration products should be configured to bypass the secure enclave executables and network IPs and ports (see bypass table below and any endpoint firewall rules to exclude by application).
4. 3rd party VPNs that are running on the endpoint are required to be configured as split-tunnel or split-exclude configurations (based on bypass table below) to bypass traffic for the secure enclave from going through the VPN.
5. Network firewalls must be configured to allow Private Company Gateway traffic based on layer 3 TCP/UDP, as well as any layer 7 application or protocol level blocking for WireGuard VPNs (see network firewall rules table below).

Windows Endpoint Firewall Rules

Network Firewall Rules

Bypass rules for network firewalls, DNS filtering, web filtering, proxies, VPN

Detailed Overview

There are four types of traffic and firewall and proxy rules that need to be considered:

1. Endpoint firewall rules - traffic between Workplace apps and our backend services can be blocked at the endpoint. In the case of Secure Enclave applications, all traffic that enters the Workplace Gateway interface happens on the device and should have endpoint firewall rules configured for 3rd party firewalls. Workplace automatically adds required endpoint firewall rules to the Windows Defender Firewall.
   • Common issues:
     • Firewalls that deny all outbound traffic except allowed lists will need to configure the rules below. In addition to the ule below that will open up Venn Secure Enclave to connect, rules for specific apps must be implemented. For example, Chrome should be allowed to talk on port 80, 443 tcp+udp so you can access websites.
       
       
2. Endpoint DNS rules - traffic between Workplace apps and our backend must resolve hostnames for several domains. While Venn maintains a good standing and has Business category classifications in the majority of DNS web filtering vendors in hardened environments it may be necessary to allow list Venn hostnames.
   • Common issues:
     • DNS filters configured to block unclassified domain categories or new domains will frequently have false positives and will require adding Venn to allow lists.
3. Endpoint proxies, web gateways, VPNs - software such as zScaler, Netskope or CloudFlare VPN may be configured to hijack all traffic on the endpoint as well as blocking for specific services such as Microsoft 365 or Google Workspace.
   • Common issues:
     • 3rd party vendors such as zScaler, Netskope and others may restrict access to specific products such as Google Drive. Make sure products are configured to allow this traffic.
     • The following hostnames: os33.net / os33portal.net and venn.com must be bypassed by proxy and VPN products.
     • Some products allow bypassing / exclude based on application and this may be easier way to bypass secure enclave executables.
4. Network firewall rules that are required on the network once the traffic leaves the endpoint. Network devices that traffic will traverse through such as firewalls with Intrusion Prevention Software (IPS)/Deep Packet Inspection (DPI) can prevent connectivity as well.
   • Common issues:
     • Firewalls configured to block UDP traffic or have application level / deep packet inspection blocking WireGuard and/or VPN software will likely not be able to connect without first adding the rules below.
     • Firewalls configured to prevent ICMP traffic will likely block ICMP traffic that is used to determine the closest data center/Point of Presence and connectivity will not be possible. Adjust firewall rules to allow outbound ICMP traffic to common services such as Google’s 8.8.8.8 and others.
     • Firewalls configured with strict ICMP flood protection rules will likely block ICMP traffic that is used to determine the closest data center/Point of Presence and connectivity will not be possible. Adjust flood protection rules based on your vendor recommendations.

Example Use Case

With the basic overview out of the traffic out of the way, let’s review a typical use case:

A user launched Workplace, and opens Chrome inside the Secure Enclave. Here is what happens:

1. Workplace app connects to Venn backend.
   • https requests are sent to Venn backend services. Device must have ability to do DNS requests for backend services.
2. Workplace app connects to IDP to authenticate the user.
   • https requests are sent to Office 365/Okta/Google/Venn/..)
3. Workplace start internet connectivity monitoring.
   • ICMP requests are sent to well known Venn backend services and dedicated Private Company Gateway IP addresses. Connectivity to the closest data center is determined based on latency data inside the return ICMP packets.
4. Up until now all traffic is visible to both endpoint firewalls, and network firewalls.
5. Workplace Gateway connectivity is established to the closest Private Company Gateway.
   • The closest IP is determined based Step 3 latency. If the connectivity the closest VPN is not established, we automatically try to connect to the next available Private Company Gateway IP.
6. Private Company Gateway traffic at this point is encapsulated inside a WireGuard tunnel on port 443/udp.
   • Network firewalls will only see this traffic. They will not see what the user does inside the Secure Enclave. On the endpoint, the Workplace Gateway network interface operates the kernel level and firewall rules must be done without binding to a specific process.
7. Private Company Gateway is an established VPN tunnel, we will monitor to make sure this tunnel is still alive.
   • Bidirectional Forwarding Protocol (BFD) is used to monitor if packets are able to be sent across the tunnel. This is our first traffic inside the encapsulated tunnel, using port 3785/udp. If BFD detects that the tunnel is down for any reason (e.g. outage on some internet route), it will automatically initiate a reconnection attempt to the next available Private Company Gateway IP.
8. User launches Chrome and tries to connect to https://www.google.com
   • First a DNS request is send to the Private Company Gateway inside the tunnel on several ports 53/udp or 8853/udp. This traffic is encapsulated, and not visible at the network level, same as BFD traffic in the previous step. DNS on Windows is handled at the kernel level so firewall rules must be done without binding to a specific process.
   • Private Company Gateway includes DNS filtering that will then provide the right IP for www.google.com. In some cases, web filtering policies configured inside Venn Company Admin will filter certain domains and can be allowed inside our admin interface.
9. Chrome connects to the www.google.com using https
   • This traffic is encapsulated, and not visible at the network level. All customer traffic, just like Chrome traffic will be encrypted and only a single WireGuard VPN connection on port 443/udp will be visible at the network level.