mabl Link is an encrypted reverse proxy tunnel, not a VPN (Virtual Private Network).
mabl Link is designed for point and click deployment within a private network or VPC. Because of its simplicity, mabl Link can be setup in 5-10 minutes, rather than the time consuming process of configuring VPN appliances, peering networks, and coping with IPs and routes.
There is no fundamental limitation to the number of Link Agents you can use, but you should only use the number of agents you need for your respective environments. Using a large number of agents will be more complex to wire up in your environments and plans.
Because mabl Link provisions dedicated firewalls, routes, IPs, and servers on a per Link Agent basis, reusing an agent will have a significantly faster startup time (seconds), compared to the few minutes (2-5min) required to provision this infrastructure.
No. The secure tunnel is established as an outgoing connection to mabl, so the Link Agent can run even behind firewalls that block incoming connections. In fact the Link Agent does not create any listening sockets.
mabl Link connects to the mabl cloud over a TLS encrypted TCP connection (
port 443). To orchestrate the connection process and provisioning, as well as install automatic updates, mabl Link will connect to the mabl APIs (
https://api.mabl.com), and our cloud CDN provider (
See Introduction to mabl Link for a detailed description of the architecture.
Yes. All hostnames will be resolved on the respective mabl Link Agent, which is running inside your network. As long as the host running the Link Agent can resolve the DNS address, your journeys running inside mabl will be able to resolve it. This also includes addresses like
127.0.0.1, and entries in the host
Using mabl Link with localhost URLs
Please see Using mabl Link to run tests against localhost to learn how to configure mabl tests to work with
localhost URLs via mabl Link.
Yes. See above.
If your corporate network intercepts outgoing SSL traffic the Link Agent will have trouble connecting to the mabl APIs and establishing the secure link tunnel. In this case, the only current workaround is to pass the
--no-ssl-verify argument when starting the Link Agent. When this flag is enabled, the Link Agent will skip SSL certificate verification on mabl API calls. In addition, the tunnel itself will run on a port other than 443. The reason for using a different tunnel port is that the traffic traversing the tunnel is not using the HTTP protocol, so any attempt to inspect it or modify it will likely prevent the tunnel from functioning properly. By default the tunnel will use port 8443 in this case, but that can be overridden by passing a custom port using the
--port command-line argument.
The Link Agent must be able to making outgoing connections to port 443 in order to communicate with the mabl APIs. If your corporate network is blocking outgoing connections to port 443, please contact your network infrastructure team about putting an exemption in place for the Link Agent.
Yes. By default the tunnel will run on port 443, which should work in most cases. If for some reason you need the Link Agent to connect to the tunnel using a different egress port, that port can be requested by passing the
--port <port number> argument when starting the Link Agent. If a tunnel is already running on port 443 with a given agent name, you may need to choose a different agent name to start using a different port. The
--port option is most commonly required in conjunction with
--no-ssl-verify in order to work around issues with certain corporate proxy servers.
Yes. You can start multiple Link Agents with the same
--name argument. If multiple agents are running with the same name they will automatically form a high availability cluster such that if one of the agents were to become disconnected, future tests would begin to use one of the agents that is still running.
If you need redundancy then pick a general name that can be used across multiple machines.
For testing against a local build you want it to be unique. Include your specific machine name or your name as part of the Link Agent name to identify that Link Agent later when adding it to an environment.
On a Mac (OSX) or Linux machine, you may need to add the Link Agent/bin folder to your PATH.
Alternatively, you can run the agent command from the
link-agent/bin directory, or provided the full path to the
You are running an unsupported Java version. Run
java --version to see what version you are using.
As of 25 March 2019, the current IPv4 CIDR blocks are
IP Blocks Subject to Change
While these blocks are largely static, they are subject to change. To maintain an active list, consider scripting
nslookup to regularly update your routing rules, if necessary.
18.104.22.168/20 22.214.171.124/21 126.96.36.199/23 188.8.131.52/20 184.108.40.206/19 220.127.116.11/11 18.104.22.168/15 22.214.171.124/14 126.96.36.199/15 188.8.131.52/17 184.108.40.206/18 220.127.116.11/19 18.104.22.168/20 22.214.171.124/22 126.96.36.199/23 188.8.131.52/14 184.108.40.206/15 220.127.116.11/16 18.104.22.168/17 22.214.171.124/18 126.96.36.199/15 188.8.131.52/16 184.108.40.206/17 220.127.116.11/18 18.104.22.168/19 22.214.171.124/21 126.96.36.199/20 188.8.131.52/14 184.108.40.206/15 220.127.116.11/13 18.104.22.168/17 22.214.171.124/17 126.96.36.199/14 188.8.131.52/13 184.108.40.206/15 220.127.116.11/16 18.104.22.168/17 22.214.171.124/20 126.96.36.199/21 188.8.131.52/20 184.108.40.206/14 220.127.116.11/15 18.104.22.168/15 22.214.171.124/14 126.96.36.199/15 188.8.131.52/14 184.108.40.206/19 220.127.116.11/18 18.104.22.168/20 22.214.171.124/21 126.96.36.199/22 188.8.131.52/23 184.108.40.206/24 220.127.116.11/20 18.104.22.168/17 22.214.171.124/20 126.96.36.199/19 188.8.131.52/22 184.108.40.206/18 220.127.116.11/21 18.104.22.168/20 22.214.171.124/23 126.96.36.199/19 188.8.131.52/22 184.108.40.206/18 220.127.116.11/21 18.104.22.168/22 22.214.171.124/21 126.96.36.199/20 188.8.131.52/22 184.108.40.206/22 220.127.116.11/22 18.104.22.168/23 22.214.171.124/23