Qubes HVM: How to auto detect the network settings (IP, gateway) from inside the VM?

adrelanos · July 8, 2024, 5:11pm

I am using a Qubes HVM with Linux (Debian or any arbitrary Linux distribution) installed from ISO.

The network is not configured yet. Network manager DHCP is failing because Qubes does not provide a DHCP server. Therefore the network needs to be manually configured. I need to find out my assigned local VM internal IP address and gateway. No need for netmask no need because always 255.255.255.255. This could be done by looking at Qubes VM Manager in dom0 according to documentation.

However, I am looking for an alternative way that does not involve needing to look at dom0. I do not wish to use dom0 (Qubes VM Manager) to look up IP and gateway, because this cannot be automated from inside the VM.

Is there some way to auto detect the network settings IP, gateway to be used from inside the VM?

Is there some program, script to scan for this or bruteforce?

My end goal is to have a script/program to automate network configuration.

apparatus · July 8, 2024, 5:22pm

Related issue:

github.com/QubesOS/qubes-issues

Please expose network configuration details via xenstore (ip address, gateway, network mask, dns, etc)

opened 06:02PM - 19 Dec 20 UTC

Osndok

T: enhancement C: Xen P: default

**The problem you're addressing (if any)** As [mentioned in the qubes documen…tation](https://www.qubes-os.org/doc/standalone-and-hvm/#setting-up-networking-for-hvms), modern linux kernels are unable to make use of the DHCP server to configure their networking. When setting up one-off guests, it may not be too difficult for experienced users to manually fetch & copy the details from dom0, but it would be a much better user experience if this could be done automatically from within the guest through means such as cloud-init, [jeos-firstboot](https://github.com/openSUSE/jeos-firstboot/blob/master/files/usr/sbin/jeos-firstboot#L370), or even custom-written scripts. At present, it seems the only way to acquire this information from the guest would require communication over the qubes agent channel, which would effectively require qubes binaries, which others would understandably be reticent to package & maintain for such a niche. On the other hand, if the network addresses were made available available via `xenstore`, then this could be accomplished by just about any OS that supports living under xen, because they would all have the xenstore capability. **Describe the solution you'd like** I would like to see the network addresses (ip, netmask, gateway, dns) made available via `xenstore` by any means that the maintainers of qubes see fit. It would be swell if it could be done in a way that a widely-supported provisioning mechanism would already recognize (such as that `xenstore-read vm-data` json blob), or created as an entirely fresh qubes specification (such as `xenstore-read qubes/net/gateway`). In the first case, it would "just work"... which would be terrific. In the second case, it might only require the user to create a script or two such as: ``` cat - >> /etc/sysconfig/network/ifcfg-eth0 <<EOF DEVICE=eth0 BOOTPROTO=static ONBOOT=yes STARTMODE=auto USERCTL=no IPADDR=$(xenstore-read qubes/ipv4/address) NETMASK=$(xenstore-read qubes/ipv4/netmask) GATEWAY=$(xenstore-read qubes/ipv4/gateway) DNS1=$(xenstore-read qubes/ipv4/dns1) DNS2=$(xenstore-read qubes/ipv4/dns2) EOF ``` **Where is the value to a user, and who might that user be?** To the advanced qubes users, this would mean that they could create standalone HVMs that could be successfully cloned in an automatic fashion, or simply to avoid the nuisance of manually tweaking the network configuration each time. To the maintainers of the provisioning mechanisms, it would be far more agreeable (and easy) to add an extra code path to support qubes if it only required testing for the presence of a xenstore variable, than to package, maintain, and bake-in the qubes agent/db binaries. To the less-advanced qubes users, it might mean that more ISOs would "just work" going forward into the future. To the qubes maintainers & community, it might mean marginally fewer "networking doesn't work" support requests, or a lessened "qubes is too hard" disposition. **Describe alternatives you've considered** * trying to repackage qube binaries for other OSes * building my own templates * being content with the (admittedly-reasonable) limitation of "Fedora" & "Debian" guest flavors **Additional context** This came to light as I spent way too many hours trying to get an OS I was unfamiliar with (SUSE JeOS; since it has a xen image) to work as a qubes guest, 99% of the time was spent trying to manage the quirks of manually configuring networking without any of the usual nicities (being a super-lean distro). **Relevant [documentation](https://www.qubes-os.org/doc/) you've consulted** * https://www.qubes-os.org/doc/standalone-and-hvm/#setting-up-networking-for-hvms * https://www.qubes-os.org/doc/templates/ **Related, [non-duplicate](https://www.qubes-os.org/doc/reporting-bugs/#new-issues-should-not-be-duplicates-of-existing-issues) issues** * #5605 * #6145

alimirjamali · July 8, 2024, 5:51pm

I am not sure if anyone has ever wrote such a program. The logic for random IP selection comes from qubes.vm.mix.net.NetVMMixin.get_ip_for_vm(vm) function. Which itself gets the random number for non-disposables from qubes.app.VMMConnection.get_new_unused_qid function. So you are dealing with 10’000 possibilities for VM IP. And the vmid_to_ipv4 function should be reversed. Fortunately the qid allocation order is not random.

Multiplied by the Gateway IP possibilities. Overall brute-forcing should be doable and not very slow.

But I believe doing that the correct way would be by solving the xenstore issue shared by apparatus earlier.

adrelanos · July 9, 2024, 12:37pm

Qubes allows arbitrary gateway IP settings. Let’s say Qubes VM Manager (QVMM) shows Gateway 10.137.0.54 then actually a gateway setting of 10.137.0.100 will be acceptable too. So that is 1 thing less to bruteforce. Much fewer combinations to try.

However, if QVMM shows IP 10.137.0.2 then another IP such as 10.137.0.3 will be rejected. Tested with ping 4.4.4.4 shows Destination Host Unavailable.

alimirjamali · July 9, 2024, 1:36pm

~~Pinging NetVM’s primary (or secondary) DNS might be faster.~~

adrelanos · July 13, 2024, 5:28pm

To find Qubes gateway IP:

Once the permissible local VM IP has been found, traceroute Qubes primary DNS.

traceroute -m 1 10.139.1.1 | grep -v "traceroute to"

Expected output (example):

1 10.137.0.54 (10.137.0.54) 0.254 ms 0.200 ms 0.178 ms

Why traceroute? Because ping does not work.
Why | grep -v "traceroute to"? To hide traceroute’s banner to make it easier in the future to script this / parse its output.

If there was a better/faster command for that, this would help too.

Bruteforcing a permissible local VM IP is still todo.

renehoj · July 13, 2024, 5:31pm

Does qubesdb-read /qubes-gateway give the same ip?

adrelanos · July 13, 2024, 6:40pm

There is no qubesdb-read in that VM. It’s a HVM. No Qubes tools
installed at this point / maybe even unavailable.

alimirjamali · July 13, 2024, 6:53pm

I still do not get the final goal. According to Marek:

If the VM lacks PV drivers (i.e. uses emulated ethernet instead of PV one), then it will get network configuration via DHCP. This DHCP server is running within stubdomain providing the emulated device and as such is not available for PV devices.

Are we dealing with a case where no DHCP client could be run and we still need to brute force the IP?

adrelanos · July 13, 2024, 9:08pm

This is applicable to HVM too. No DHCP server available.

For all practical purposes, yes.

Kinda. There is an unimportant detail. A DHCP client can be run inside the VM but it would be of no use because Qubes does not provide a DHCP server. So the only way to not have to setup networking manually would be to burte force it.

That is, unless any of above linked tickets get implements or someone invents a better workaround.