I have a Kali Linux AppVM (not an HVM) that I created based on a tutorial about two years ago. So far it has been working but recently my eth0 shows as down and I have no idea where to start.
The initial symptom was DNS not resolving. Tried attaching it directly to sys-firewall (originally it routes through VPN, which is where I suspected the error): No change. Then noticed from the command line that eth0 is actually listed as DOWN:
user@pentest:~$ sudo ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:16:3e:5e:6c:00 brd ff:ff:ff:ff:ff:ff
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:ff:91:71:7f brd ff:ff:ff:ff:ff:ff
user@pentest:~$
I strongly suspect the issue to be in the AppVM itself as all other AppVMs are working.
What component inside the VM would bring up the interface? Read that parameters such as IP-Address and Resolvers are passed in via qubesdb, but what component receives that info and acts on it?
user@pentest:~$ dpkg -l qubes-* | grep net
ii qubes-core-agent-network-manager 4.2.36-1+deb12u1 amd64 NetworkManager integration for Qubes VM
ii qubes-core-agent-networking 4.2.36-1+deb12u1 amd64 Networking support for Qubes VM
I’ll have a look at the files it contains and see if I find and systemd untis leading me to journal-entries.
I know of its existence (wasn’T there when I created that qube) but was unsure about the differences to my (so far) working AppQube.
Looks like I found the culprit
user@pentest:~$ sudo systemctl status qubes-network*
× qubes-network-uplink.service - Qubes network uplink wait
Loaded: loaded (/usr/lib/systemd/system/qubes-network-uplink.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Wed 2024-08-07 13:06:10 CEST; 1h 42min ago
Invocation: 55eb52bd9b8845c8977013126e6b2826
Main PID: 530 (code=exited, status=1/FAILURE)
Aug 07 13:06:10 pentest systemd[1]: Starting qubes-network-uplink.service - Qubes network uplink wait...
Aug 07 13:06:10 pentest systemd[1]: qubes-network-uplink.service: Main process exited, code=exited, status=1/FAILURE
Aug 07 13:06:10 pentest systemd[1]: qubes-network-uplink.service: Failed with result 'exit-code'.
Aug 07 13:06:10 pentest systemd[1]: Failed to start qubes-network-uplink.service - Qubes network uplink wait.
× qubes-network-uplink@eth0.service - Qubes network uplink (eth0) setup
Loaded: loaded (/usr/lib/systemd/system/qubes-network-uplink@.service; static)
Active: failed (Result: exit-code) since Wed 2024-08-07 13:06:10 CEST; 1h 42min ago
Invocation: c6ed17b24da547a39c5e2f2b5d0e1f36
Main PID: 617 (code=exited, status=127)
Aug 07 13:06:10 pentest systemd[1]: Starting qubes-network-uplink@eth0.service - Qubes network uplink (eth0) setup...
Aug 07 13:06:10 pentest setup-ip[649]: /usr/lib/qubes/setup-ip: line 30: /sbin/ip: No such file or directory
Aug 07 13:06:10 pentest systemd[1]: qubes-network-uplink@eth0.service: Main process exited, code=exited, status=127/n/a
Aug 07 13:06:10 pentest systemd[1]: qubes-network-uplink@eth0.service: Failed with result 'exit-code'.
Aug 07 13:06:10 pentest systemd[1]: Failed to start qubes-network-uplink@eth0.service - Qubes network uplink (eth0) setup.
Some part of the setup-ip script expects the ip command to live in /sbin, which under Kali it does not. The following fixed it for me:
sudo ln -s `which ip` /sbin/ip
I am however not entirely sure about the consequences or what introduced the breaking change.
For now it works. I’ll give the kali template a go though.
