I don’t quite understand what difference it makes, which template. Remmina does a great job and Novnc shows the start page
I tried with client based on debian-12 and server based on whonix-17 and I was able to connect from the browser.
The only thing I changed from my previous setup was to start novnc with this command instead:
websockify -D --web=/usr/share/novnc/ 6080 localhost:5901
Then it was accessible on http://127.0.0.1:6080/vnc.html and I was able to connect with the password set on tigervnc inside the whonix workstation qube.
1 Like
Everything works. You’re a great Jedi warrior) Do I propose to solve another problem?)
Nice.
Sure, what is it about?
1 Like
I now have an untrusted-device. Inside untrust-vm (with novnc server) I have a hotspot running with a separate wifi adapter. I connect untrusted-device to hotspot(utrust-vm inside qubes) and want to access vnc through a browser. However, I tried both device roles. The hotspot was either untrust-vm with a wifi adapter or untrusted-device with its own adapter, but in both cases I was unable to connect to utrust-vm either through a browser or via ssh. One clarification, dhcp for hotspot inside qubes doesn’t want to work in any template.
nmcli device wifi hotspot con-name myConn ssid MySSID band bg password 12345678
You should probably create a dedicated qube for your adapter, like it’s done with sys-net. No netvm, “provides network” enabled with just the adapter attached to it, then you connect the qubes you want to use it with so it does its own thing and doesn’t mess with other qubes networking.
1 Like
I don’t quite understand how this solves the problem. If I make a direct network inside untrust-vm, it at least has some external IP, and when connected to sys-net-2, it has the IP that distributes qubes, and it’s not so easy to access the service behind the nat. It doesn’t bother me that the adapter will work in untrust-vm, because it’s already networkless.
I’m not sure I understood the problem then. From what I understood in your previous message, you have an adapter attached directly to your qube where novnc is installed and it cuts off the ability to connect to your vncserver or use ssh. That’s why I told you about isolating the adapter to its own qube, so that whatever happens to the network inside your novnc qube stops and is only forwarded to the adapter if necessary.
When you say that you can’t connect, do you mean that you try to access the service from a device outside Qubes?
1 Like
That’s right, I can’t access the qube service from an external device.
As far as network isolation is concerned, you may be right, but it won’t affect security much, because the untrust-vm qube doesn’t have anything of value, it’s only built for VNC translation and isn’t connected to the network, it can be disposable after all, so network isolation doesn’t make sense.
Since this is incoming traffic, it might be blocked by the internal qubes firewall.
For example, you could allow port 6080 in your novnc qube (where the adapter is) with nftables and see if it’s accessible from outside:
sudo nft add rule ip qubes custom-input tcp dport 6080 accept
2 Likes
Everything is great! I am very grateful to you! You will get a better incarnation or you have nothing left to do in this mortal world)
1 Like