How to create a secure corporate tunnel using RustDesk

Why avoid RustDesk public servers in a corporate setting?

When using RustDesk out of the box, it typically connects to public servers maintained by the developers or the community. In practice, this means that while video feeds and mouse controls are encrypted, the initial connection handshake routes through third-party infrastructure. For an enterprise handling sensitive data, legal compliance, and rigorous auditing, this dependency introduces an invisible risk.

Hosting your own signaling and relay infrastructure resolves this structural dilemma. By controlling the server, you ensure that no access metadata—such as source and destination IP addresses, timestamps, or session keys—traverses networks you do not directly manage. This follows the same security principles applied when configuring dedicated infrastructure, such as resilient networks with dual-WAN failover to keep critical operations running smoothly without single points of failure.

Understanding the relay and signaling architecture

For RustDesk to operate without external intermediaries, we must understand two fundamental components running on the server: the signaling service (named hbbs) and the relay service (named hbbr). In practice, hbbs acts as a phone book letting each computer know where others reside on the internet, whereas hbbr acts as a direct tunnel when two computers cannot talk directly due to corporate firewall barriers.

When two devices sit on the same local network or establish direct routing paths, the connection is peer-to-peer. However, if restrictive firewalls block the path, traffic must bounce through hbbr. This is where end-to-end encryption shines: even though data flows through your relay server, it travels scrambled with mathematical keys known exclusively by the originating client and the target machine. To ensure this infrastructure remains healthy, proactive monitoring practices, much like those found in predictive Grafana alerting setups, help anticipate service degradations.

Preparing the environment and deploying with Docker

The cleanest and most isolated way to run RustDesk components is via Docker containers, which bundle the software with all its dependencies without cluttering the host operating system. Below is a functional example of a docker-compose.yml file to deploy both the signaling and relay daemons on a dedicated cloud Linux server or on-premise hardware.

version: '3'
services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs -r your-ip-or-domain:21117
    volumes:
      - ./data:/root
    ports:
      - 21115:21115
      - 21116:21116/udp
      - 21117:21117
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    volumes:
      - ./data:/root
    ports:
      - 21118:21118
      - 21119:21119
    restart: unless-stopped

Once the file is saved, run the following command in your terminal to bring the services up in continuous background operation. Make sure to replace your-ip-or-domain with the actual reachable address of your corporate server.

docker compose up -d

Configuring ports and security keys

The ports used by RustDesk must be properly opened on your server firewall and cloud provider security groups. Port 21115 handles TCP registration, port 21116 manages UDP discovery and direct connections, 21117 runs the ID service, while ports 21118 and 21119 manage the video relay tunnel.

In addition to opening the correct ports, the data directory mapped in Docker will generate a public key file ending in .pub. This key acts as the entry ticket for your company's clients: only applications configured with this specific key will be allowed to register against your corporate server, preventing unauthorized machines from attempting brute-force logins or exploiting access vulnerabilities.

Configuring clients to point to the private server

With the server up and running and ports opened, the next step is configuring employee workstations and remote target servers. In the RustDesk application installed on each machine, open the network settings and enter your server IP or domain in the ID Server and Relay Server designated fields.

Also paste the public key generated by your server into the encryption key field. In practice, this means that from that moment on, the client machine will stop searching public servers on the internet and will report exclusively to your internal corporate infrastructure, keeping all sessions under strict control and traffic monitoring.

Auditing and compliance for remote access sessions

One of the greatest advantages of maintaining a self-hosted tunnel is the ability to audit team behavior. Because traffic passes entirely through your hardware, the logs generated by the hbbs container record precisely which user connected to which machine, session start times, and total duration.

These logs can be forwarded to centralized log analysis tools to comply with information security frameworks such as ISO 27001. In the event of an incident, the security team can rapidly trace the origin of suspicious access, guaranteeing a level of corporate governance impossible to achieve with generic, decentralized remote access utilities. To explore these architectural concepts further in production, see our related technical analysis on Slow Zabbix? How to scale PostgreSQL for high data volume.

Final considerations

Deploying a secure corporate tunnel with RustDesk combines the flexibility of modern remote access with the security rigor demanded by today's market. By isolating infrastructure on your own servers, you protect sensitive data against interception and maintain absolute control over enterprise information flows, establishing a reliable technological foundation for distributed operations.