Qubes Inplace upgrade from 4.1-4.2 issues

Qoobsnoob · January 13, 2024, 3:09pm

Im not getting any pings on either.

I think i found the culprit however. In another thread it mentioned mac address randomization is causing some issues. I used this guide (Anonymizing your MAC address)

After deleting the 50-macrandomize.conf, it works.

But this presents a problem because i need mac address randomization.

Ps. Brb

apparatus · January 13, 2024, 3:20pm

There is no use in randomizing the MAC address of virtual interfaces in VMs. Only randomizing the MAC address of your physical network controller in e.g. sys-net make sense.
The MAC addresses are only seen withing the same physical segment e.g between between sys-vpn and sys-firewall. The VPN provider won’t be able to see the MAC address of the virtual interface in the VM just based on the network packets.

Qoobsnoob · January 13, 2024, 4:11pm

What if i have an application running in vm1, and my setup is sys-net → sys-firewall → sys-vpn → vm1.

Some applications are able to read hardware identifiers right? Would applications in this scenario be able to read mac address? If so, which ones?

apparatus · January 13, 2024, 4:28pm

The app running locally in VM will be able to read the MAC address of its virtual interface.
This MAC address is the same for all qubes 00:16:3e:5e:6c:00:

github.com/QubesOS/qubes-issues

Possible tracking of DVMs

opened 12:37AM - 10 Apr 20 UTC

closed 09:23AM - 10 Apr 20 UTC

e6lk7dqzm83p

T: bug R: not applicable P: default

**Qubes OS version** 4.0 **Affected component(s) or functionality** Disposa…ble VMs **Brief summary** I was accidentally booted from a Zoom meeting by a friend and I decided to see if I could rejoin from a new DVM with a new IP address (used a different VPN server), when I tried to rejoin (with a different user name) I got an error that I had already been booted from the meeting. Given how DVMs should be working this should not be possible. It appears that Zoom (at the server side) is some how able to track between different DVMs (even with different underlying OSes). **To Reproduce** Start a DVM, install Zoom Join a meeting Get booted from the meeting Start a new DVM with an new IP address, install Zoom Try to join a meeting **Expected behavior** Zoom cannot track behavior between different DVMs **Actual behavior** Zoom seems to be able to track behavior **Additional context** I tried this with multiple DVMs with different IP addresses (Fedora and Debian) and with Whonix, none were allowed to rejoin. The meeting ID is not unique for participants and I was able to rejoin from a VPN via my cellphone using the same meeting ID (i.e. the meeting isn't locked). My VPN is run via Tasket's Qubes-vpn-support (https://github.com/tasket/Qubes-vpn-support).

Qoobsnoob · January 13, 2024, 4:37pm

Makes sense. Thank you so much foe your time!

Insurgo · January 13, 2024, 6:03pm

This is done by default under Qubesos sys-net since a really long time under paid grant work (wifi) but not wired connection. I agree: there is no use randomizing mac outside of sys-net. The reason is that mac addresses are only used on physical layer of TCP/IP: only switches and router directly connected to your machine will see it, no other device (misconception of what a mac address is and what it is used for).