This page relates to the legacy version of the tunnel that has been introduced to CrossBrowserTesting. If you use the new tunnel version, see Local Testing — Secure Tunnels.
Enterprise Connection Manager is a utility to give network administrators maximum control over CrossBrowserTesting’s Local Connection Feature.
What does it do?
Normally enabling Local Connection establishes a WebSocket tunnel between CrossBrowserTesting’s devices and the user’s computer. Some network environments do not allow users to establish that kind of tunnel. And some network administrators need to be able to audit and control the tunnel traffic.
That is where the Enterprise Connection Manager comes in. When ECM is enabled all Local Connection requests by all users will go through the ECM, instead of the users’ computers.
If run from a DMZ the network administrator can have complete control over what can be accessed over a Local Connection.
How do I use it?
First, make sure that your account is enabled to use the Enterprise Connection Manager. Contact Support if you need help with this.
Install with NPM
npm install -g cbt-enterprise-connection-manager
Install with Git
Clone this repository:
git clone https://github.com/crossbrowsertesting/connection-manager
Move to the new directory:
Download the dependencies:
Optional: create a link to a folder in your path:
ln -s cbt-enterprise-connection-manager.js ~/bin/cbt-ecm
Install with pre-compiled binary
Coming soon! If this is something you would like to see ASAP, contact Support.
Then run it!
If you installed it with
cbt-enterprise-connection-manager --username <email address> --authkey <authkey>
If you didn’t:
./cbt-enterprise-connection-manager --username <email address> --authkey <authkey>
How does it work?
ECM establishes a long-running secure websocket connection to CrossBrowserTesting. When a user requests a Local Connection, a message will be sent over the websocket to the ECM asking it to start a Local Connection tunnel for the user. As far as the user is concerned, our service will operate the same as it always has but the tunnel will start from the ECM, not their machine.
Be aware that users will not be able to enable Local Connection if the ECM is not running.
How do I troubleshoot issues with my Local Connection?
The difficulty with troubleshooting Local Connections lies in all the unknowns present in users’ environments. Office networks, corporate local networks, and home connections are subject to any number of potential access-restricting devices and software. The good news is there is nearly always a way to connect with CBT via one of our tunnel options.
The CrossBrowserTesting Chrome extension is the most straightforward implementation of our Local Connection tunnel. Once installed and enabled according to the instructions provided, begin a Live Test on a site such as https://whatismyip.com. If you see your location/IP address through our app, then the Local Connection is functioning properly and no networking troubleshooting is required.
The Chrome Extension and Node.JS/Binary tunnel use the same manner of connection, so if the Chrome Extension works, so should the Node tool.
If your Local Connection does not function in a Live Test, properly or at all, then your first course of action should be to verify Port 443 is open for traffic to and from CrossBrowserTesting. This can be done by performing a WebSockets Test. If reaching out to CrossBrowserTesting Support for further troubleshooting, please include your Results ID with your inquiry.
You should see the following results for Port 443. If you do not, please consult with your Network staff to resolve this issue.
If you are using a Proxy Server, you must additionally configure steps for the Local Connection to function. As we have no way of determining this, the best option is to ask your Network staff. If applicable, they will provide you the appropriate IP and Port information to enter into the Proxy Server settings within the CrossBrowserTesting App. Similarly, you must input the appropriate Proxy Server parameters for the Node.JS Local Connection tunnel as described in the tool’s documentation.
If you have successfully verified Port 443 is open to CrossBrowserTesting traffic, and that you either do not have a proxy server or you have applied the appropriate configuration changes, then the issue may be present in your network’s firewall.
Once again, it is imperative that you ask your Network staff if CrossBrowserTesting may be blocked by certain firewall rules. If this is the case, our Support staff may provide you a consistent IP address to be put on the allow list.
Once you have verified the issue does not lie in the most common areas listed above, you may reach out to us at Support or via Intercom and we will be happy to help. Please indicate that you have performed the steps as described in this document and that you have consulted with your network staff to try and resolve the issue.
Ports needed opening to connect behind a firewall
Most firewalls will allow users inside the firewall to initiate connections outwards, so the following will not apply. For users with restrictive firewall policies that prevent outgoing connections or outgoing VNC connections, please read the following.
CrossBrowserTesting provides the Live Test service via a VNC client to connect and display the remote browser. In your account’s settings, there are three options for browser-based VNC clients, and one option for a Desktop-based VNC client.
Ports required to be open by VNC client type
HTML5: Uses port 443 over HTTPS via WebSockets (WSS).
VNC Client: Uses port range 5920-6100 over TCP.
By default, traffic from a Live Test connects to livetest.crossbrowsertesting.com. Traffic on this subdomain runs across a "high-speed network" which improves the responsiveness of your test session. However, this address resolves to changing IP addresses based on an analysis of the fastest path. Because the resolved IP address varies, it is easier to set firewall rules for a consistent IP address using our standard domain: crossbrowsertesting.com(Please contact support for the IP address).
To set up a firewall rule with our consistent IP address, follow these steps:
Turn off the "High-Speed Network" setting in your account settings, which will resolve our outgoing VNC connections to crossbrowsertesting.com (see image below).
Add a rule to your firewall allowing connections initiated from inside your network on port 80 and ports 5920-6100 to our IP (please contact support for the IP address).
If you are using the HTML5 client you may also need to allow for port 843 and 443 outbound to crossbrowsertesting.com.
If you want to continue to use the High-Speed Network, leave the High-Speed Network setting on, and configure your firewall to allow connections initiated from inside your network on port 80, 443 and / or ports 5920-6100. Do not try to filter on destination IP address, as it will continually change.
If you are using a desktop VNC client, it will always use a port from 5920 - 6100. The HTML5 clients use port 80 or 443 to connect.
Have questions or need help on this? Call us or send an email.
Struggling with security certificates
If you experience issues opening your internal page having SecureTunnel on, it can be helpful to test a SecureTunnel connection with “Bypass tunnel for public URLs” and “Accept all SSL Certificates” unchecked.
Bypass tunnel for public URLs
Selecting this check box enables the tunnel to resolve publicly accessible sites without having to route through your machine– it will only attempt to resolve a domain name through your computer if it cannot resolve it publicly. This will generally speed up tests when enabled since many sites call publicly available resources.
Accept All SSL Certificates
When selected, all certificates are considered valid in the tunnel. This is useful for development versions of sites that may be using self-signed or invalid certificates.
Running SmartBear Secure Tunnel through the command line
Download the following binary file:
Windows: https://sbsecuretunnel.s3.amazonaws.com/cli/windows/SBSecureTunnel.exe Linux: https://sbsecuretunnel.s3.amazonaws.com/cli/linux/SBSecureTunnel MacOS: https://sbsecuretunnel.s3.amazonaws.com/cli/macos/SBSecureTunnel Note: If you have the desktop tunnel executable installed, you can find the file link on the Command Line tab.
After you downloaded the file, open the command-line window, type the executable name and specify the user name and authentication key in the command line. You can find an example in the Command Line tab:
For complete information on the command-line arguments, see SecureTunnel Command Line.
Allowing traffic from our cloud IPs
When testing web applications that are running in private networks, you need to allow traffic between your servers and CrossBrowserTesting cloud machines. CrossBrowserTesting uses these URLs and addresses:
Most testing traffic = 184.108.40.206app.cbt.com
Headless Testing = 220.127.116.11
SmartBear Secure Tunnel = geo.tunnel.smartbear.com
|Asia Pacific (Mumbai)||ap-south-1||
|Asia Pacific (Sydney)||ap-southeast-2||
|US East (N. Virginia)||us-east-1||
|US West (N. California)||us-west-1||
You can check which region applies to you by using the inspector during a recording. It is also possible to go to Application > Local Storage > recorder-region.
Safari won’t connect to local server using acceptallcerts. It is unable to connect to Mac with local tunnel, but it works for Windows.
Specify the IP address of the tested server, for example
18.104.22.168, only ever worked for most desktop browsers during live testing. Selenium creates a new profile on Firefox which has its own proxy settings per version
Invalid Host Header Error
While testing an application hosted on your local machine, you may receive the “Invalid Host Header” error message when you use a local connection. This error is commonly caused by the misconfiguration of the application server that causes it to reject non-local connections.
Most development-oriented application servers (like ng, webpack-dev-server, or WAMPP) by default allow traffic from
localhost only, . In some cases, traffic is blocked directly. Essentially, only traffic directed to your machine from the machine itself is allowed to pass through. This means that traffic passing through the tunnel will not work the same as traffic coming from your machine directly.
Even though it works on your machine, server settings make connections from other local machines impossible.
In most cases, you can restart the server and allow connections from outside
Shut down the server and restart it, add
--host 0.0.0.0 --disableHostCheck true to the command.
Shut down the server and restart it as above, but add
--host 0.0.0.0 --disable-host-check instead.
Shut down the server and restart it, add
--host 0.0.0.0 to the command. Sometimes it requires adding
--disable-host-check here as well.
If you can’t find your server listed here, or prefer to do it some other way, most likely you can find a quick solution by searching for “yourServer bind ip” on Google.
To run from another location, you need access to an HTTP proxy in that location. To do that, go to https://free-proxy-list.net to find an open HTTP based proxy. The challenging part of the process is finding an HTTP based proxy that is open, available, and reliable.
To get started with your own testing:
- Run a local connection by pressing Local Connection in Test Center.
- Click the Proxy tab inside the Local Connection options.
- Enter the proxy information you gathered previously.
- Press Connect.
Now, run your tests. Your location should be reported as a country you have chosen. If you have geo-based content or ads, you will be able to see if they are working as they should.
Testing not possible even after allowing traffic from main IP
In the past, address ranges were blocked by Cloudflare IP as well, even though the main IP was allowed.
Cloudflare provides the list of IP ranges which are not blocked. Here, you may verify these addresses https://www.cloudflare.com/ips/.
Also, some networks have proxy avoidance rules setup. These, like Bluecoat Proxy, flag traffic for blockage. If the Cloudflare IPs are not blocked, verify if users network uses the type of proxy avoidance rule. If so, to add us to the allowed list. A potential test for this is the ability to visit https://smartbear.com/.