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

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 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.

Related issue:

1 Like

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.

1 Like

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

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

1 Like

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

To find Qubes gateway IP:

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

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

Expected output (example):

1 ( 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.

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

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

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?

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.

1 Like