Qubes Inplace upgrade from 4.1-4.2 issues

Qoobsnoob · January 13, 2024, 2:06pm

I got the same results for sys-firewall, the proxyvm im having issues with and sys-net.

Changing my dvm to sys-firewall, im able to connect to websites fine. However my proxy vms are not able to connect

Qoobsnoob · January 13, 2024, 2:08pm

I can confirm the issue is only with vpn vms

apparatus · January 13, 2024, 2:15pm

How did you configure your VPN qube?

Qoobsnoob · January 13, 2024, 2:23pm

Most are configured like this: Using network manager, i added the .ovpn config files with user name and password. Then i went into firewall settings for that qube and added the IPs.

The one odd ball is riseup vpn. They dont give out ovpn config files for it so i defaulted to using the app which never gave me issues on 4.1.

I also have mac address randomization set to every start via a script.

apparatus · January 13, 2024, 2:44pm

Do you have any firewall rules add/remove (using iptables of nft) in the config file?

Qoobsnoob · January 13, 2024, 2:47pm

I havent touched iptables/nftables at all

apparatus · January 13, 2024, 2:52pm

Not by yourself, there could be iptables commands in .ovpn config.

apparatus · January 13, 2024, 2:54pm

https://forum.qubes-os.org/t/which-vpn-do-you-use/3406/143

Qoobsnoob · January 13, 2024, 2:54pm

Ohh. How can i check this?

apparatus · January 13, 2024, 2:55pm

Check the content of .ovpn file and see if there are any iptables there.
Or any up/down scripts.

Qoobsnoob · January 13, 2024, 2:55pm

‘Doesnt exist or is private’

apparatus · January 13, 2024, 2:56pm

On another topic

On another topic

The VPN that I currently used is RiseupVPN because I don’t need to setup any accounts and already has a snap software that is already has ready-to-use flag/mode within it.

Riseupvpn too here.

One of the debian maintainer made a really amazing job mainstraining it under debian-12 (bookworm), meaning sudo apt install riseup-vpn works in debian-12 template, while setuping a proxyvm depending on that template and launching the app on VM start is all that is needed for q4.1. But unfortunately, nftables changes broke it(q4. 2).Will try to open an issue. Riseupvpn deserves users rich enough to donate according to their bandwidth usage, as usual in the “free world” (nothing is free, someone has to pay for those projects/services to continue to exist and pay their infra/workforce costs).

I found an amazing project though: GitHub - kmille/riseup-vpn-configurator: a simple command line tool to get RiseupVPN up and running
I’m planning to use it and try to plug it with GitHub - tasket/Qubes-vpn-support: VPN configuration in Qubes OS
They also both deserve our donations if used.

I’ll try to work on the plumbing and do a pr soon under tasket repo. Would love to add a donation reminder somewhete there but not sure it would fly with mindset of neither projects out of the main official client. Idea there welcome.

.

Qoobsnoob · January 13, 2024, 2:57pm

I dont see any. Checked 2 vpn providers .ovpn files

apparatus · January 13, 2024, 3:02pm

Can you ping from your VPN qube?

ping quad9.com
ping 9.9.9.9

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