Re: [qubes-users] Q: USB tethering
On Wed, Apr 01, 2020 at 12:04:00AM +0200, Ulrich Windl wrote: > I had been asking this before: How hard will it be to use USB tethering in > Qubes OS? As in: use the USB connection to your phone as network interface? The (standard) way I do it is to assign the USB controller to sys-net. The rest kind of happened automatically after installing the respective tools (I use an iDevice). Unless you are using a desktop PC with a USB keyboard, this is also the much safer approach (instead of having USB directly handled in dom0). If you however use a USB keyboard things could get ugly and more planning is needed. > Mar 31 22:55:57 dom0 kernel: usb 2-10.2: Manufacturer: HUAWEI Yep, wouldn't want this anywhere near dom0. Not that I trust my iDevice substancially more, but I think you get the idea. /Sven -- public key: https://www.svensemmler.org/0x8F541FB6.asc fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200401002455.GC1128%40app-email-private. signature.asc Description: PGP signature
[qubes-users] Q: USB tethering
Hi! I had been asking this before: How hard will it be to use USB tethering in Qubes OS? Dom0 seems to recognize the interface, but I cannot assign it to any VM: Mar 31 22:55:57 dom0 kernel: usb 2-10.2: new high-speed USB device number 8 using xhci_hcd Mar 31 22:55:57 dom0 kernel: usb 2-10.2: New USB device found, idVendor=12d1, idProduct=108a, bcdDevice= 2.99 Mar 31 22:55:57 dom0 kernel: usb 2-10.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Mar 31 22:55:57 dom0 kernel: usb 2-10.2: Product: WAS-LX1A Mar 31 22:55:57 dom0 kernel: usb 2-10.2: Manufacturer: HUAWEI Mar 31 22:55:57 dom0 kernel: usb 2-10.2: SerialNumber: 2345678987 Mar 31 22:55:57 dom0 kernel: usbcore: registered new interface driver cdc_ether Mar 31 22:55:57 dom0 kernel: rndis_host 2-10.2:1.0 usb0: register 'rndis_host' at usb-:00:14.0-10.2, RNDIS device, 06:69:31:77:66:aa Mar 31 22:55:57 dom0 kernel: usbcore: registered new interface driver rndis_host Mar 31 22:55:57 dom0 kernel: rndis_host 2-10.2:1.0 enp0s20u10u2: renamed from usb0 Regards, Ulrich -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4c9d8409-526d-5f52-f7d7-cd704e7bc3a9%40rz.uni-regensburg.de.
[qubes-users] dom0 qubesd[4917]: unhandled exception while calling src=b'dom0' meth=b'admin.vm.property.Get
Hi! While examining networking problems, I noticed this traceback in Dom0's journal: Mar 31 22:57:15 dom0 qubesd[4917]: unhandled exception while calling src=b'dom0' meth=b'admin.vm.property.Get' dest=b'sys-firewall' arg=b'start_time' len(untrusted_payload)=0 Mar 31 22:57:15 dom0 qubesd[4917]: Traceback (most recent call last): Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib/python3.5/site-packages/qubes/__init__.py", line 227, in __get__ Mar 31 22:57:15 dom0 qubesd[4917]: return getattr(instance, self._attr_name) Mar 31 22:57:15 dom0 qubesd[4917]: AttributeError: 'AppVM' object has no attribute '_qubesprop_start_time' Mar 31 22:57:15 dom0 qubesd[4917]: During handling of the above exception, another exception occurred: Mar 31 22:57:15 dom0 qubesd[4917]: Traceback (most recent call last): Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 275, in respond Mar 31 22:57:15 dom0 qubesd[4917]: untrusted_payload=untrusted_payload) Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib64/python3.5/asyncio/futures.py", line 381, in __iter__ Mar 31 22:57:15 dom0 qubesd[4917]: yield self # This tells Task to wait for completion. Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup Mar 31 22:57:15 dom0 qubesd[4917]: future.result() Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result Mar 31 22:57:15 dom0 qubesd[4917]: raise self._exception Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step Mar 31 22:57:15 dom0 qubesd[4917]: result = coro.send(None) Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro Mar 31 22:57:15 dom0 qubesd[4917]: res = func(*args, **kw) Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 156, in vm_property_get Mar 31 22:57:15 dom0 qubesd[4917]: return self._property_get(self.dest) Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 186, in _property_get Mar 31 22:57:15 dom0 qubesd[4917]: value = getattr(dest, self.arg) Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib/python3.5/site-packages/qubes/__init__.py", line 230, in __get__ Mar 31 22:57:15 dom0 qubesd[4917]: return self.get_default(instance) Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib/python3.5/site-packages/qubes/__init__.py", line 237, in get_default Mar 31 22:57:15 dom0 qubesd[4917]: return self._default_function(instance) Mar 31 22:57:15 dom0 qubesd[4917]: File "/usr/lib/python3.5/site-packages/qubes/vm/qubesvm.py", line 2019, in start_time Mar 31 22:57:15 dom0 qubesd[4917]: return float(start_time) Mar 31 22:57:15 dom0 qubesd[4917]: TypeError: float() argument must be a string or a number, not 'NoneType' Doesn't look quite right... ;-) Regards, Ulrich -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d83882cb-bdd1-52f4-056f-e771c9a4c69e%40rz.uni-regensburg.de.
[qubes-users] More on network issue "send queue timed out"
Hi!
Today I was booting Qubes OS after having run Windows 10. I was unable
to get a network connection, even after booting several times.
The message in sys-net was the infamouse "send queue timed out" while
DCHP was repeatedly requesting a lease (but did not receive any response).
Eventually I unplugged the cable, let all the VMs start up and
stabilize, the plugged in the cable again, and I had networking!
I'm unsure which of the unusual messages I had saved are related to the
real problem. Anyway here are some:
First Xen hypervisor itself:
(XEN) Freed 316kB init memory
(XEN) Bogus DMIBAR 0xfed18001 on :00:00.0
(XEN) [VT-D]DMAR:[DMA Read] Request device [:05:00.0] fault addr
c653f000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 02 - Present bit in context entry is clear
(XEN) [VT-D]DMAR:[DMA Read] Request device [:05:00.0] fault addr
c653f000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 02 - Present bit in context entry is clear
(XEN) [VT-D]DMAR:[DMA Write] Request device [:05:00.0] fault addr
c653f000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 02 - Present bit in context entry is clear
Unsure which device this is related to, maybe Firewire?:
5:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire
II(M)] IEEE 1394 OHCI Controller (rev 46)
From sys-net:
CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz (family: 0x6, model: 0x3c,
stepping: 0x3)
...
Performance Events: unsupported p6 CPU model 60 no PMU driver, software
events only.
Not enabling interrupt remapping due to skipped IO-APIC setup
The message above logs call traces in the journal, but due to missing
kernel symbols the call trace is undecodable:
...
Call Trace:
? 0x81a78e8f
? 0x81a675cd
? 0x81a78fdd
? 0x81a5ed95
? 0x81217a24
? 0x81217a29
? 0x814001b5
Code: c2 48 83 f8 ff 48 0f 45 c2 c3 48 c7 c0 a8 5a 80 81 c3 48 c7 06 ff
00 00 00 c3 48 89 f8 b9 00 04 00 00 48 89 f7 48 89 c6 f3 a5 c3 <0f> 0b
89 f8 c3 89 f8 c1 e8 18 c3 31 c0 c3 31 c0 c3 0f 0b c3 31
Then some more odd messages:
acb817a0-0010-49ef-96c1-86ccbedd84eb
[00:06.0] xen_pt_realize: Assigning real physical device 00:00.0 to
devfn 0x30
[00:06.0] xen_pt_register_regions: IO region 0 registered
(size=0x0100 base_addr=0xd000 type: 0x1)
[00:06.0] xen_pt_register_regions: IO region 2 registered
(size=0x1000 base_addr=0xf7d0 type: 0x4)
[00:06.0] xen_pt_register_regions: IO region 4 registered
(size=0x4000 base_addr=0xf030 type: 0x4)
{"execute": "device_add", "arguments": {"driver": "xen-pci-passthrough",
"id": "xen-pci-pt_-03-00.0", "hostaddr": ":00:00.00",
"machine_addr": ":03:00.0", "permissive": false}}
[00:06.0] xen_pt_config_reg_init: Offset 0x000e mismatch!
Emulated=0x0080, host=0x, syncing to 0x.
[00:06.0] xen_pt_config_reg_init: Offset 0x0010 mismatch!
Emulated=0x, host=0xd001, syncing to 0xd001.
[00:06.0] xen_pt_config_reg_init: Offset 0x0018 mismatch!
Emulated=0x, host=0xf7d4, syncing to 0xf7d4.
[00:06.0] xen_pt_config_reg_init: Offset 0x0020 mismatch!
Emulated=0x, host=0xf03c, syncing to 0xf03c.
[00:06.0] xen_pt_config_reg_init: Offset 0x0042 mismatch!
Emulated=0x, host=0x07c3, syncing to 0x0603.
[00:06.0] xen_pt_config_reg_init: Offset 0x00d2 mismatch!
Emulated=0x, host=0x8000, syncing to 0x8000.
[00:06.0] xen_pt_config_reg_init: Offset 0x0052 mismatch!
Emulated=0x, host=0x0080, syncing to 0x0080.
[00:06.0] xen_pt_config_reg_init: Offset 0x0074 mismatch!
Emulated=0x, host=0x5908cc0, syncing to 0x5908cc0.
[00:06.0] xen_pt_config_reg_init: Offset 0x007a mismatch!
Emulated=0x, host=0x0010, syncing to 0x0010.
[00:06.0] xen_pt_config_reg_init: Offset 0x0082 mismatch!
Emulated=0x, host=0x1011, syncing to 0x1011.
[00:06.0] xen_pt_pci_intx: intx=1
[00:06.0] xen_pt_realize: Real physical device 00:00.0 registered
successfully
{"return": {}}
Unfortunately it seems journal messages in sys-net do not survive reboots.
Regards,
Ulrich
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/febc6e3b-61d6-f2c3-69df-26e0e5f878fb%40rz.uni-regensburg.de.
Re: [qubes-users] Cloning a DVM: some apps don't start disposably
On Fri, Mar 27, 2020 at 09:09:12AM +, tetrahedra via qubes-users wrote: I have a dispVM `my-dvm` where everything works as it should: if I open Firefox, that Firefox instance starts in a new disp VM. I want to clone that dispVM and create a new dispVM connected to a different network-providing VM, so I do exactly that: clone `my-dvm` and set the netVM for `my-new-dvm` to `my-other-netvm`. When I start XTerm in `my-new-dvm` the new XTerm window starts in a disp disposable VM, as it should. When I start Firefox in `my-new-dvm`, however, Firefox starts up in the underlying `my-new-dvm` template, not in a disp disposable VM. This means that the Firefox browsing history and prefs are saved, any malware gets to persist, etc. Comparing the output of `qvm-prefs my-new-dvm` and `qvm-prefs my-dvm`, all settings are identical except for things that should obviously be different (the netvm, the GUID, the IP address, etc). After further testing, the problem does not appear when cloning a Whonix workstation dispVM -- the problem only appears when cloning a Fedora-based dispVM. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200331213554.GA1071%40danwin1210.me.
[qubes-users] Re: thinkpad x220: ," unsupported hardware error" during install, black screen after install
Solved ! See the github issue for more info : https://github.com/QubesOS/qubes-issues/issues/5744 -- Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com Mar 27, 2020, 22:57 by cacaosu...@tutanota.com: > > > > > During qubes installation, the wizard trigger an "unsupported hardware error" > on my x220, saying that VT-d is not enable, which is weird because it is in > the BIOS settings. I tried to continue with the install anyway, but when I > boot on qubes all I get is a black screen. > > Is very weird, because this is actually a reinstall. I had qubes installed on > exactly the same hardware just a few month ago. > > > > I have tried to install both R4.0.3 and R4.0, and same result. > > > > > Anyone had similar issue or could give a clue on how I could solve this. ? > > > > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/M3cBDxu--3-2%40tutanota.com.
Re: [qubes-users] Building a new pc for running Qubes OS
On 2019-11-01 14:57, M wrote: I’m thinking about building a new pc for running Qubes OS with the following specifications: 1) Motherboard: ASRock X570 Pro4 2) CPU: AMD Ryzen 3 3200G with onboard graphic (until they release one for PCIe 4.0 with onboard graphic) 3) SSD: AORUS Does anyone know about if this will result in any problems in relation to running Qubes OS besides “the ordinary challenges”, and if so which problems ? Did you happen to get any responses to this? Or if you already built it how is it working? (I am starting to think about putting a box together so am trying to take notes from others posts) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/73b5cecb-3705-e523-495e-0e15865d35d4%40posteo.net.
Re: [qubes-users] How many CPU threads is recommended for Qubes OS ?
On 2019-11-09 01:46, M wrote: How many CPU threads is recommended for Qubes OS ? Is 4 enough, or should I go for 8 or more... ? I have bought the Ryzen 3 3200G, but I could change it for another one with more threads (for example the Ryzen 3400G), if it is recommended as I haven’t unpacked it yet. Hi, did you get any responses to this? I am looking to build a new(ish) Qubes computer so clarity on this would be useful. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f38a1201-717d-35d4-d7c9-33e290f2c643%40posteo.net.
Re: [qubes-users] Dependency problem in Qubes packages when updating to current Debian testing (bullseye)
On Mon, Mar 30, 2020 at 07:11:41PM +0200, Phil Kn??fer wrote: > Hi @all, > > I just followed the guide on converting a Debian template to Kali Linux. > Apart from a new naming convention in Debian 11 repositories > (bullseye/updates has been renamed to bullseye-security) everything > worked fine. > > When executing the ''apt dist-upgrade'' I realized that the packages > "qubes-core-agent-dom0-updates" and "qubes-vm-recommended" were to be > removed. This seems to be due to the fact that > "qubes-core-agent-dom0-updates" requires yum and yum-utiles, which both > seem to be missing in Debian Testing. > > The former package is described as "Scripts required to handle dom0 > updates." I don't think that I will ever use a Debian Testing/Kali-based > VM for updating dom0 so this should not be a problem. However, > "qubes-vm-recommended" depends on this package and therefore is removed > during the upgrade. > > Is this a known issue? Maybe a bug that needs to be addressed in the > packages? > > According to my tests/research "qubes-vm-recommended" is only a > metapackage that specifies some dependencies which are recommended for > best performance. All these dependencies should already be installed > anyway and can still be installed manually if there are any problems. > > If you are a regular Qubes user and experience the same problem that I > described above, there is likely nothing you need to do. > > I would have created a bug report but I don't really know where it > should go. Would https://github.com/QubesOS/qubes-meta-packages be the > right place? > > Regards, > Phil > Hi Phil Yes this is a known issue, and the workaround you have found is good. There is no problem in removing the "qubes-vm-recommended" package, and putting a hold on packages that you want to keep. I'm reluctant to take any bugs against debian-testing , ( and teherfor Kali or any distro based on testing), because it is *testing* and you expect breakage. It wouldnt be worth Qubes making mitigations against issues that will probably be fixed as testing moves to stable, imo. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200331151249.GA27350%40thirdeyesecurity.org.
[qubes-users] Re: Install Qubes in Odroid H2,
In order for Qubes to work inside KVM your CPU would need to support nested virtualization. Either switch your hardware or install baremetal W dniu sobota, 28 marca 2020 22:40:03 UTC+1 użytkownik elo...@gmail.com napisał: > > I install Ubuntu mate 18.04.4LTS Bionic in x86_64bits, in mate 1.20.1 in > Personal computer Odroid H2, my computer have a CPU J4105 Intel celeron. I > install the libraries for the virtualization of the QEMU virtual machine > manager, creating a KVM, QEMU supports Xen type hypervisors. > > The creation of the virtual machine has the following configuration. > > Considering that my personal computer has 8 GB of RAM and 4 TB of disk > space, I have allocated 2 CPUs, 4 GB of ram and 100 gigabytes of storage > space, the iso image that I downloaded from the official website is Qubes > 4.0.3 x86_64 bits.iso, is loaded from the hard disk to start > virtualization. The virtual network interface is assigned to the device > model of the network card, but I can also choose, virtio. > > The installation has no failures, except the warning that my hardware does > not support supports IOMMU / VT-d / AMD-Vi. > > When I start Qubes, the last line fails. > Failed to start Qubes VM sys-net. But the system loads equally, I start > Qubes manager. > > When I try to start whonix -ws, the warning becomes apparent, / usr / bin > / qvm-start, sys-firewall failed: stdout: > stderr: failed to start and HVM qube with PCI devices assigned-hardware > does not support IOMMU / VT-d / AMD-Vi > > I try to configure the devices, adding network cards, but I get the same > results.* In the Bios I have the VT-d display enabled*, I don't know what > else to do, in which I have the PVH mode enabled by default, and I have > also tried the HVM mode. > > and tried to update sys-whonix, in terminal, and it shows me the same Qube > HVM boot failure message. > > Other collateral errors are, Start failed: invalid argument: could not > find capabilities for arch = x86_64, see > /var/log/libvirt/libxl/libx-driver.log for details. > > The sys-firewall qube is network connected to sys-net, which does not > support firewall. > > You may edit the sys-firewall qube firewall rules, but these will not take > any effect until you connect it to a working firewall qube. > > Other comments like PVH, mode is hidden since it doesn't support PCI > passthrough. > > [image: 20200320_023124.jpg] > > [image: 20200320_024218.jpg] > > > I just need to know how to make the HVM mode work, and know how I can > transfer files from my USB, since the recognition of USB devices also > fails, everything else works perfectly. I have noticed that my Qubes is > something different, I give an example. > > In the following video https://www.youtube.com/watch?v=yrDo0q9qSXs=937s, > at minute 37:54, in the option Domain: anon-whonix many options appear, > while I only see one. Only Qube settings. > > Thanks, and for the culture, I must not stop trying. > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/95373d4f-7f01-4292-b302-99a76ad30379%40googlegroups.com.
Re: [qubes-users] Me (anon-whonix AppVM) -> Tor -> VPN, settup with Mullvad VPN
Chris Laprise:
> On 3/29/20 5:16 AM, scurge1tl wrote:
>>
>>
>> Chris Laprise:
>>> On 3/27/20 5:02 AM, scurge1tl wrote:
>>
Hello all,
I would like to ask about proper setting of AppVM flow if using
Mullvad VPN. I would like to connect to the clearnet following way: Me
- -> Tor -> VPN -> clearnet.
When setting up mullvad in their web page, I set the parameters for
download here https://mullvad.net/en/download/openvpn-config/ in a
following way:
- - All countries (so that I can change my exit country as needed)
- - Port -> TCP 443 (Tor doesn't use UDP, right?)
- - tick Use IP addresses
>>>
>>> Using TCP 443 for the connection helps only if you are running the VPN
>>> on top of Tor. With Tor on top of VPN, you're probably better off
>>> with UDP.
>>
>> Would this mean, if I plan to go with Me -> Tor -> VPN -> clarnet, to go
>> with UDP mullvad settings? Just to clear the "on top of".
>
> To make it less ambiguous:
>
> AppVM -> sys-whonix -> sys-vpn -> sys-net
>
> The above connection is Tor on top of (or inside of) VPN, so UDP can be
> used for the VPN. If sys-whonix and sys-vpn places were reversed, then
> VPN should switch to TCP mode.
>
> An easy way to remember this is that the sys-* VM attached to the AppVM
> is the one the service sees on the other end.
>
>>
>>>
To set the Mullvad VPN AppVM, I followed this guide from micahflee
https://micahflee.com/2019/11/using-mullvad-in-qubes/ The AppVM with
mullvad is vpn-mullvad. All works fine and connects to the network.
How should I connect Me -> Tor -> VPN -> clearnet? Am I right with
this setup (I didn't launch it yet): anon-whonix -> sys-whonix ->
vpn-mullvad -> sys-firewall, or I should use different setup?
>>>
>>> Whonix has a guide that examines the issues of combining Tor and a VPN.
>>> However, I think its better as a 'what-if/why' guide than a Howto...
>>>
>>> https://www.whonix.org/wiki/Tunnels/Connecting_to_a_VPN_before_Tor
>>
>> Thank you I will check it.
>>
>>>
Are there any other steps to follow to prevent leaks?
>>>
>>> Yes.
>>>
>>> The Qubes-vpn-support project is much easier to setup and should work
>>> more smoothly, in addition to providing better protection against leaks:
>>>
>>> https://github.com/tasket/Qubes-vpn-support
>>>
>>> There is also a VPN setup guide on the Qubes doc page (this is the one
>>> the Whonix page links to). FWIW, I wrote the scripts for both but the
>>> idea for Qubes-vpn-support was to automate the setup and improve the
>>> connection handling of Openvpn so re-connection doesn't take 5 minutes.
>>> It also checks the firewall to make sure leak prevention is in place
>>> before initiating connections.
>>
>> I will try to set the additional AppVM for this and try this guide. What
>> would be the linking of the AppVMs, if I would like to go Me -> Tor ->
>> VPN -> clearnet? Is it like anon-whonix -> sys-whonix -> mullvad-AppVM
>> -> sys-firewall ?
>>
>> Also I would like to use different exit countries of choice, so I
>> downloaded all countries from mullvad. Is there any simple way to switch
>> countries with this VPN settings?
>
> There is no GUI way to do it when using the Qubes scripts. However, if
> you use the Network Manager method on the Qubes vpn howto, then you can
> import multiple configs (and cross your fingers that they can make
> connections :) ).
>
> For a non-GUI solution, you could create a small script that lets you
> choose which ovpn config to use, and 'cp' or 'ln' that choice to the
> config filename that the scripts use (then restart the vpn). Some people
> have used simple random selection without a prompt, like 'ln -s $( ls
> *ovpn | shuf | head -n1 ) vpn-client.conf'.
>
>> Sorry for noob questions, I am new to the VPN stuff, just used Tor only
>> till now, but I need to use tor-unfriendly services from time to time
>> and even if it were tor-friendly, ExitNodes {xx} StrictNodes 1 doesn't
>> work in qubes-whonix and I therefore can't select exit country easily if
>> I need to. So I need to have the VPN country as a strict exit.
>
> To use Tor-unfriendly services, the service has to see the VPN IP not
> Tor exit node IP. Therefore...
>
> AppVM -> sys-vpn -> sys-whonix -> sys-net
>
> If you add sys-firewall (or similar proxyVM, as you probably don't want
> to change sys-firewall netvm setting) in the mix, it just depends on
> which VM you wish to add 'Qubes firewall' rules to it always goes
> 'to the right of' whichever VM you added rules. In my experience,
> however, such rules are not required for securing a VPN link; The
> internal (scripted) rules used by the VPN doc or Qubes-vpn-support
> handle VPN security rather well. IOW, its better to forget placing
> sys-firewall in the loop, at least until you're more used to Qubes
> networking.
>
>>
>> Thank you and I will let you know if it works!
>>
>
>
Thank you for your help. I have written an email to your address
