P2P connection behind a Firewall

[GuillaumeHullin]

I'm exploring how P2P connections work, especially with a RustDesk instance behind a pfSense firewall on a local network, with only standard ports forwarded.

I'm experimenting with NAT and will share updates. Any advice is welcome.

Below is the docker-compose.yml for RustDesk running on Debian:

services:
  rustdesk-server:
    container_name: rustdesk-server
    ports:
      - 21115:21115       # NAT type test
      - 21116:21116       # TCP hole punching and connection service
      - 21116:21116/udp   # ID registration and heartbeat service
      - 21117:21117       # Relay services
    image: rustdesk/rustdesk-server-s6:latest
    environment:
      - RELAY
      - LIMIT_SPEED
      - TOTAL_BANDWIDTH
      - SINGLE_BANDWIDTH
      - ALWAYS_USE_RELAY
      - "ENCRYPTED_ONLY=1"
      - "RUST_LOG=info" # Debug level
    volumes:
      - /root/rustdesk/data:/data
    restart: unless-stopped

This setup is behind a pfSense firewall, with ports 21115-21117/tcp and 21116/udp forwarded to the Debian machine (no home router, pfSense is directly connected to the Internet).

Current observations:

• Two clients on the same LAN connect directly.
• A local client connecting to a remote one uses a relay connection.
• A VPN client connects directly to a LAN client if all traffic is via the VPN.
• A VPN client connects to a LAN client via relay if the VPN routes only LAN traffic.

My questions: how does the RustDesk server decide that P2P is possible... I'm guessing when he sees 2 client with the same public IP?

[GuillaumeHullin]

Alright, reading rendezvous_server.rs I understand that when both client are from the same public IP, then it is assumed that they are potentially reachable directly between them.

I found this which explains some:
https://github.com/rustdesk/rustdesk/wiki/How-does-RustDesk-work%3F

Also I'm not fully understanding what is the problem in not using --net=host in Docker.

I found this explanation: https://rustdesk.com/docs/en/self-host/rustdesk-server-oss/docker/

--net=host only works on Linux, which makes hbbs/hbbr see the real incoming IP Address rather than the Container IP (172.17.0.1). If --net=host works fine, the -p options are not used. If on Windows, leave out sudo and --net=host.

But... with or without --net=host... my rendezvous_server sees the correct public IP addresses of the clients.
Also I figure that both of my clients are running behind an ISP router + pfSense ... so 2 NATs. So could be an extra difficulty.

I tried to dabble with Outbound NAT... without too much luck.

[xlionjuan]

You need network_mode: host to let application inside container see the real IP

[xlionjuan]

Except the bandwidth is surprisingly large, other settings looks fine, having any problems?

[xlionjuan]

After the long times, I realized the rate that RustDesk able to punch hole successfully isn't high, I hope they can implement UPnP feature some day, or like Parsec, specify a custom port, and let user setup port forwarding itself.

[GuillaumeHullin]

Except the bandwidth is surprisingly large, other settings looks fine, having any problems?

No, I just wanted to remove any bottleneck for speed when doing file transfer (as all my connections are going via relay).

[xlionjuan]

#371 (reply in thread)

Increase HBBR_SINGLE_BANDWIDTH

[GuillaumeHullin]

I adjusted my bandwidth variable ;) true... it was too big. Doesn't improve P2P but at least make more sense when reading a conf.