Cloudflare for Teams alongside Wireguard, performance issues

I am supporting an existing setup where people are accessing a browser-based collaborative tool via a Wireguard tunnel, and was attempting to roll out Cloudflare for Teams browser isolation alongside it. When CF for Teams is connected, performance when accessing the server on the far side of the tunnel becomes noticeably slower and even erratic.

The non-routable range on the far side of the Wireguard tunnel is in the 10.x.x.x /8 that is excluded from Cloudflare for Teams by default. I also explicitly added the public IP address for the Wireguard server to the exclude list, but neither of these changes had any impact.

I have had to undo the rollout of CF for Teams to all of these users as a result of this. Am I missing something obvious?

@tobezuk can help here, justin - he’s PM for Cloudflare Browser Isolation

Hi @justin.cordesman!

Is my understanding of your use case correct?

  • You have a self-hosted browser based collaborative tool hosted in a private network. This is accessed through your own self-managed wireguard tunnel.
  • Then when you started rolling out Cloudflare for Teams with Browser Isolation, your connection to the remote application inside your self-hosted wireguard tunnel performed poorly.

If my understanding is correct, you can use Cloudflare for Teams to connect back to your private subnet and remove the need to run parallel tunnels.

Alternatively if you wish to keep running parallel tunnels, you would actually want to add a split tunnel rule for your Wireguard endpoint. For example if its Public IP is 192.0.2.1, add a split tunnel rule for 192.0.2.1/32.

Not exactly, there are several related services hosted on the same remote server, currently accessed over a Wireguard tunnel. Client machines speak to the server on multiple ports, and most of of the services are HTTP, but one is not.

I have two issues with trying to use CF for Teams to replace Wireguard and maybe you can point me in the right direction.

The first problem is that the behavior of the non-HTTP TCP service does not seem to work with CF for Teams. I tried to use CF for Teams bastion mode to have a separate VM sitting next to it to deal with this, but the problem is that the license key server that runs on this server sees the server address being used by the client in the handshake from the client. With bastion mode that meant the client requesting a key was telling the license key server that it was connecting to “localhost:5000” for example. The license key server knows its address as part of its own key, so it does not believe it is called “localhost” and immediately closes the port. Queries to that license key service need to be addressed to either to its non-routable IP or its FQDN.

The second issue is what made me create this question on the forum - performance issues that appeared after rolling out browser isolation. A collaboration service runs on the same server as the license key service. This can be accessed with a thick and a thin/browser client. My initial test user did not report that there were intermittent performance and stability issues with the thin client after I enabled browser isolation for their account, and they were not a thick client user. When I broadened the rollout to a mix of thick/thin users it became clear that for some reason even though the non-routable range being forwarded over the Wireguard tunnel was excluded from browser isolation, it was causing intermittent connection failures and timeouts for both the thin and thick client (which had different behaviors apparently due to different timeout tolerances). I rolled browser isolation back from all users, then spent some more time testing the thin client in my own environment and just poked through the user interface while turning CF for teams on and off. The impact on login time and load times was very noticeable and if you poked it enough you’d get a timeout on occasion.