Is there a "HOST_ALIASES" like workaround for the browser client?

Hi there

My ThinLinc Server is behind NAT, so, I went for the “HOST_ALIASES” parameter configuration on client side because it seems alot easier and quick to setup as an user rather than using my sysadmin powers and configure split DNS and firewall port just for my use.

But someone randomly on the internet had problems with installation and asked for help to install ThinLinc on Ubuntu. I then created a kvm/qemu virtual machine on my host, installed Ubuntu on it with ThinLinc and it worked (I had a problem with ThinLinc server installer that I will try to reproduce and report if I encounter the same problem again). And then I found a new problem: My Virtual Machine was also behind a NAT on my host (NAT on NAT)

So, I faced a new problem that has many solutions that demand different skills, but I want to keep it on the most simple and easy. The problem was: how to connect to the ThinLinc Server running on a VM running on a NAT’ed host? To mention some of the discarded solutions:

  • I could make my host use a another physical ethernet port passed-through to my VM (I had hardware access, a network card and it is relatively easy to passthrough a network card on virt-manager, but I didn’t want to expend a network card only for this and what would be if I had more VMs?);

  • I could make my only available network card to work as a bridge and make my host and all the VMs attach to virtual network cards connected to the same bridge… If I managed to do that kind of setup, the VM(s) would be “on the same network level” and it wouldn’t count as a NAT behind NAT but would be transparently accessed as if they were just another physical machine on the network. I’ve done that kind of virtual network card configuration once before but I completely forgot how to do that. Also, I would need to configure my DHCP server to accept all the incoming virtual MAC Addresses and that’s something that I can do, but many people would not be allowed to do this, either because they don’t control the network or they don’t have necessary permissions.

So, the most basic option for me was to mix two solutions: port-forwarding and HOST_ALIASES: I just learned that libvirt has a feature that I may set a “qemu-hook-script” that launches whenever I start a VirtualMachine… and I’ve found this github user doccaz that gently improved the official libvirt suggestion and shared his solution here: Doccaz’s kvm-scripts. By using his qemu-hook-script saved as “/etc/libvirt/hooks/qemu” and tuned to my needs, each time I start a VirtualMachine it will automatically create an iptables rule that starts port forwarding from host to vm guest. And then I could for example port-forward my host port 22222 to VM’s port 22 and I would just need to configure my HOST_ALIASES parameter on my clients targetting that VM pointing VM’s IP Address port 22 to my host’s IP address port 22222… Also, if working from outside the network, I could create a ssh tunnel to my host’s IP address port 22222 and set my HOST_ALIASES to point my VM’s IP Address port 22 to the tunneled ssh port.

And then It would be perfectly solved because creating the port-forwarding host->VM was kinda easy and I already work with ThinLinc’s client HOST_ALIASES parameter, but something remained in my head: What about the web client running on the VM? I mean, I can port-forward some host port to port 22 on the VM and fix the forwarding with HOST_ALIASES as if it was a ssh tunnel, but how would I configure it access the VM’s IP port 300 to host’s forwarded port? Because the web client doesn’t have any HOST_ALIASES configuration to do and my host machine has no DNS server running so I could use something like split-DNS.

I did a simple test:

  • Sucessfully port-forwarded HOST_IP:30000 to VM_IP:300;
  • Sucessfully accessed HOST_IP:30000 on web browser running on another machine on same host’s network;
  • Failed after entering login credentials because the URL changed to try VM_IP:300, something that HOST_ALIASES would fix if I was using ThinLinc Client.

I have two guesses, but was not able to test yet: either configure client machine’s “hosts” file (/etc/hosts) to point VMs’s IP to my host IP (does that work?) OR configure the VM’s ThinLinc server to answer my host’s IP address instead of the VM’s IP Address, simillar to when we use Split DNS and have the ThinLinc server answer its DNS name instead of IP Address.

So, I’ve been stuck on this problem and I hope that I didn’t mess everything with some crap explanation, hahahaha. Reason for this topic is because I found that it is very useful for my job that I can use my machine remotely from a web browser and fix anything that I need on the servers. Sometimes I go to another user’s room to find out that the solution is to change a configuration on a server that needs my stored private key credentials to access. Instead of bothering another sysadmin or going back all the way to my room to make the needed changes, I simply borrow a private tab on users’s browser to connect to my machine through ThinLinc. But what would happen if my machine was a VM behind a NAT? Is there an easy solution?

1 Like


There is currently no such functionality in the web client. The solutions you’re suggesting sound very complicated, it may be less effort in the long run to obtain a public IP address and avoid having to deal with NAT altogether.