Control exposure
Never expose TCP port 5900 to the internet or forward it from an internet router. Use a VPN, an SSH tunnel or an approved overlay network for remote access. Limit VNC reachability to the intended network or hosts, including when you use a different VNC port. For an SSH tunnel, keep the VNC listener on localhost. Check your organisation’s remote-access policy before choosing the path.
Restrict VNC to your network
Keep VNC on your trusted LAN, VPN or authenticated tunnel. For a host already using UFW, this example allows TCP 5901 (display :1 at its default port) from your LAN subnet. Replace 192.168.1.0/24 with your actual subnet, and confirm the server’s configured port before using it.
- Add the LAN allow rule:
sudo ufw allow from 192.168.1.0/24 to any port 5901 proto tcp - After the allow rule, add the deny rule for TCP 5900–5910 from anywhere:
sudo ufw deny proto tcp from any to any port 5900:5910 - Inspect the rules:
sudo ufw status numbered
Have the administrator review existing rules and verify access from both an intended client and outside the allowed subnet. Never forward TCP 5900 from an internet router to the Pi. For a Pi listening on 5900, use the range alternative below only if both ports should be allowed; this display :1 example does not enable access to 5900.
Test this on your own host before relying on it.
If you need both ports
Replace the single-port allow step above with sudo ufw allow from 192.168.1.0/24 to any port 5900:5901 proto tcp. Replace the subnet with your actual LAN subnet. Then follow the deny and inspection steps above. Use this alternative only when you intend to allow both TCP 5900 and 5901.
Test this on your own host before relying on it.
For hosts using firewalld
This is a subnet allow example for TCP 5901. Replace the subnet with your LAN subnet:
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port port="5901" protocol="tcp" accept'
Then run sudo firewall-cmd --reload.
Ask the administrator to review the active zone and existing rules and verify that other sources cannot reach VNC. This allow rule alone does not establish exclusive access.
Test this on your own host before relying on it.
Encrypt sessions
Prefer encrypted sessions and check which parts of the connection are encrypted. RFB’s original VNC authentication is a password challenge, not session encryption: RFC 6143 section 7.2.2 describes the authentication exchange, and section 9 explains the base protocol’s lack of protection against observation or tampering. Use an encrypted session mode agreed by the viewer and server, or carry VNC through an encrypted tunnel or VPN. SSH encrypts traffic carried through its tunnel.
Authentication and MFA
Define who may connect and how they authenticate. Include MFA in your requirements and verify whether it protects the account, the connection or both. Plan how to revoke credentials and respond to repeated sign-in failures. Give each person only the access their task needs, using view-only access where available.
Patching and version currency
Record the server and viewer versions in use and follow their release channels. Keep VNC and any SSH software in the connection path patched. Check instructions against the versions you actually run, and stop or disable servers you no longer use.
Logging and access review
Decide which connection attempts to log and which repeated failures should trigger an alert. Inspect authentication logs and review access on a schedule. Write down who may reach each system, from which networks, and who owns the review. Remove people and devices that no longer need access.
Offboarding
When someone no longer needs access, remove their access and any device authorisations they no longer need. Revoke the relevant credentials and change shared session or account passwords where necessary. Stop unused remote-access servers and include these checks in your access-review process.
Sources accurate as of 30 September 2026.
Commercial or open source?
Open-source VNC suits personal projects and home labs. When your business depends on remote access, RealVNC Connect adds end-to-end encryption, centralised management and commercial support from the team that created VNC.
With either approach, decide who owns exposure control, authentication setup, patching and access reviews.