Monthly Archives: April 2022

mullvad (or other wireguard) and tailscale coexistence – tailscale not pinging

my linux to linux tailscale connection would not ping, except that ‘tailscale ping’ itself worked. i rememnbered I also had mullwad. looking a bit, I found this wonderful post with explanations on how it all actually works. the guy rebooted to have it work tho, and I didn’t want to reboot.

I did the systemctl fix he suggested (despite the “before” and “after” confusion in his conclusion and “fix” sectiion, weird), but restarting units a few times in different orders (including the tailscaled unit) didn’t help and the rules stayed the same as in his “broken” example, tailscale rule after mullwad rule in ‘ip rule’ order.

do read the post for insights, but still, in short, this helped:

sudo ip rule add preference 5207 from all lookup 52
sudo ip rule delete preference 5270

looks like this can be put in a script, too, and the rules stay consistent between installations? idk. likeeee, check ‘ip rule’ output and script things at your own risk.

importing vm from virtualbox to qemu, and a small virt-aa-helper fight

I used ubuntu 20.04 or something

First, I used this tutorial to convert the vdi image to qcow2. I then installed qemu and libvirt and co on my new vm host system, moved the files there and used some long command I no longer remember to create a new virtual machine using some libvirt thing? I had to activate “default” network for that command to work, IIRC.

virt-viewer helped me connect to the vm’s screen, and it showed “booting from hard disk” and got stuck there, turned out I had to add an UEFI image because that’s what VirtualBox also used or smth. I used “virsh edit” for that IIRC, opening an xml file that was unexpectedly easy to read and modify, and this snippet in the <os> section helped:

<loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE.fd</loader>

We did it, Reddit. This is all you need.
It’s tempting, but wrong, to add this too:

<nvram>/usr/share/OVMF/OVMF_VARS.fd</nvram>

You absolutely should not add the <nvram> section, only the <loader> one. Seems like qemu will try to write into the <nvram>-located file, and if you give it the OVMF_VARS.fd file, virt-aa-helper will throw apparmor-looking errors. saying “error: skipped restricted file” and even “internal error: cannot load AppArmor profile”.

It might look like apparmor is shouting at you, but if you look at syslog and kernel.log messages carefully, it’s actually virt-aa-helper, an additional layer of defense and protection way before apparmor even gets a chance to react. Adding or editing apparmor profiles will do nothing!

Changing the virt-aa-helper’s behaviour requires recompiling libvirt, but you don’t have to – just don’t add any nvram store and let qemu/libvirt/whoever add its own store, it will appear on its own in the xml file next time you launch the machine, I think.

from there… don’t touch it, I guess? or touch it, I’m not a cop. Anyway, that’s how my 1h+ detour into apparmor finished, with “just remove the nvram section with the /usr/share default file”. Makes sense that each guest gets its own nvram that’s assigned automatically, tbf.