Hello,
Can anyone explain how VNC is implemented in VM, Instances?
As far as I understand, it is part of the boot package.
I’m wondering how communication can still be happening even without any NIC configured.
thx
Stefan
VNC in TrueNAS connects to the TrueNAS host and presents a local VGA, keyboard and mouse to the VM.
Thanks for the clarifying answer!
So, a VNC server can be accessed via TCP/IP.
It is ‘hardwired’ to the instance’s own VGA, keyboard, and mouse.
Therefore, depending on the network layout, if an instance is compromised, the host should still be safe.
Is this correct?
How can I limit access to the VNC server in a multi-NIC scenario?
Is this only achieved by assigning an IP address to the NIC (Bridge, VLAN or Hardware) that will be used for VNC administration?
Is there any chance that users in a different VLAN to the administration VLAN could accidentally gain access to VNC?
Check out Network Configuration for New Instances in TrueNAS SCALE 25.04 Fangtooth - #15 by PackElend for an explanation of what I mean by a multi-NIC scenario.
Yes.
Yes.
That’s one of the points of virtualisation. Unless the VM can reach the host over the network and some malware inside the VM is actively looking to exploit the host, of course.
Theoretically it should not be possible to “escape” a virtual machine - correct.
As far as I am aware VNC shares the IP address with the UI. Limit access to the UI and you limit access to VNC.
If the NAS host has an IP address in that VLAN, yes. If there is only a layer 2 connection for VMs via a bridge interface, then there must be some kind of router or firewall between those VLANs and whether users can access the UI or not depends on the configuration of that firewall.
HTH,
Patrick
It depends on your definition of safe I suppose.
The risk of a VM escape is not theoretical, there’s even a Wikipedia page on it with a long list of known vulnerabilities:
To be clear though, they are somewhat rare. Due to the doors such a vulnerability can open in today’s cloud based world, they are valuable, and don’t appear to see widespread usage. Probably kept for high profile targets.
1 Like
But you could say that they are relatively safe.
I don’t see any CVE younger than 2020 (but it not neccessarly a reason to say, it is 100% safe).
I’m just a little confused about which interface to use for the IP of the UI: bridge or VLAN?
In other words, the only way to prevent access to the host is to ensure that the IP does not suggest that the host can be reached using other network techniques.
IP set, other host can reach TN if in same network, IP not set, not reachable. Looks like that there is not full network isolation.
Correct. Full network isolation only exists for VMs and as far as I know Incus containers.
1 Like
Nothing is ever 100% safe, even if there are and have never been any CVEs. It doesn’t mean someone can’t find a new way or maybe no one wanted to previously. Safer maybe, but not 100% safe, ever.
that is what I meant 
the only thing what confuses me here, when I create an MACVLAN interface of an existing BRIDGE or VLAN interface on TN.
As I have different Pool of Apps for different network segments, I have to use VLAN interfaces.
As soon as I put an IP on such an interface I open the door to the host.
I have difficulties to accept, that this simple setting plays are importan role in network isolation.
That is because Docker containers do not have a separate virtual network stack and corresponding interfaces. In the end it’s always the FIB of the host that is used.
This is different from VMs or “real containers” like LXC or jails. Docker simulates a container implementation with cgroups, which are essentially namespaces but not isolated containers.
That’s why it s* so hard.
you refer to
?
thanks for sharing these details
Yes, forwarding information base.
1 Like