Re: [qubes-users] Archlinux Community Template Qubes OS 3.2
@Olivier Medoc First off, thank you for all the work you've clearly put into the Arch Linux build and documentation for Qubes. FYI, I'd just like to add my own experiences when I tried to use the new template. (Since I was using the ready-built template, I skipped your build instructions and started at section "Package Manager Proxy Setup Section".): 1. After the initial download, the template VM wouldn't close down and was eventually killed by the qubes-dom0-update script. That behaviour was repeated after I started and tried to shutdown the template VM myself.2. Just like Francesco, I had difficulty reading the command lines, because it is virtually impossible to distinguish a single- from a double-dash and copy/paste wasn't working. I tried in both Firefox and Chromium so it wasn't browser related. A fixed-pitch font should do the trick.3. Since gnome-terminal wouldn't open, it would have been useful if you had specifically named the "archlinux terminal app" for those of us not versed in Arch Linux. I used xterm as a fallback, which worked, but later found out that there is an xfce4-terminal that is very like gnome-terminal.4. Step 3 Install Pacman failed with an error about a database file not existing. Some research led me to try "pacman -Syy" (I think without "sudo") which did the trick. 5. Step 7 Configure Powerpill... the description (though not the example) omits the need for a comma on the preceding line. Otherwise, it's now all up and running. Now all I have to do is get my head around Arch! Mike -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/K_LP0VH--3-0%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installing VPN in Qubes Versus VPN on a Router
13. Nov 2016 16:01 by no...@noses.com: > > Am 13.11.2016 um 14:22 schrieb > hed...@tutanota.com> : > > >> 13. Nov 2016 08:48 by >> amad...@riseup.net>> : >> > Thoughts on thispaper and it's conclusions are welcomed > >> > > There is a point where additional components won't give you > defense-in-depth but only additional complexity that will in the endmake > you less secure. > > Allowing a backdoored router into your network will, complexity or no complexity, compromise your security. The only conclusion to reach is not to use them wherever possible, or isolate them if their use is mandatory. > >> >> An always-on VPN connection on the router works well but can bea bit >> slow since the processing power of router CPUs isgenerally quite >> limited. If choosing a router, I'd suggest adual-core ARM-based >> device. Although openvpn is onlysingle-threaded you can usually >> configure cpu-affinity to placeit on one core and the other routing >> tasks on the other core. >> > > One of the GL-Inet small arm(s 8-) ) routers is sufficient for 80 > MBit/s (see > https://www.gl-inet.com/> ). I'm using one of their "Mifi" > devices (> https://www.gl-inet.com/mifi/> ) to write this and right nowit > is holding up quite well with 150 MBit/s LTE plus an OpenVPN ontop of it. > The only problem is the about 1MBit/s I'm getting fromtheir uplink. > > I've never come across these devices. They look like good value for money. > >> >> For those who want to go beyond around 20-25 Mb/s, which iswhere an >> ARM router will start to reach its limits >> > > Seriously? I doubt that. Right now I'm using an ASUS RT-AC5300 (ARM, > dual core) router on a 400/20 MBit link (residential cable) and evenif > I'm sturating it using an OpenVPN process running on the routerits cores > seem quite unimpressed. But maybe DD-WRT is magical. > Yeah, maybe my 25 Mb/sec generalisation is a bit out-of date but it still depends on what you're prepared to spend. Let's see: ASUS RT-AC5300. It has 8 antennas and is a beast of a router that sells for 439 euros on amazon.de. At that price it really ought to be fast. Back in more reasonably-priced territory, I did some real-world tests 18 months ago on my ASUS RT-AC56U (97 euros on amazon.de, ARM x 2) and never exceeded 25 Mb/s with 80% cpu load. Even had it achieved 100% cpu, that would still only equate to 30 Mb/s. Flippant comments about magic aside, if you throw big mony at the hardware, you'll get more speed. I'm still betting that a small i3 with AES-NI would outperform it on openvpn, and for a fraction of the price. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/KWTqII3--3-0%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installing VPN in Qubes Versus VPN on a Router
13. Nov 2016 08:48 by amad...@riseup.net: > We see much correspondence in these forums about installing a VPN within > Qubes. Surely, the most secure place for VPN is to install on a Router? > I say these things after reading the following paper [ > > https://cryptome.org/2013/12/Full-Disclosure.pdf> ] in which a group of > hackers demonstrate that the majority of routers (in-particular those > provided by ISP's] have backdoors to government agencies. These adversary's > are able attack our LAN and its devices; including the ability to intercept > VPN and Tor traffic. > The solution they say is to isolate these rogue routers in the Militarized > Zone by creating a DMZ [demilitarized zone]. Achieved by installing a 2nd > router [flashed with open source firmware such as OPenWRT]. It is here, on > the router, that we should enable and run OpenVPN. > Thoughts on this paper and it's conclusions are welcomed > > An always-on VPN connection on the router works well but can be a bit slow since the processing power of router CPUs is generally quite limited. If choosing a router, I'd suggest a dual-core ARM-based device. Although openvpn is only single-threaded you can usually configure cpu-affinity to place it on one core and the other routing tasks on the other core. For those who want to go beyond around 20-25 Mb/s, which is where an ARM router will start to reach its limits, a fine alternative is a small fanless PC, such as the Intel NUC or Gigabyte Brix, and run an open source firewall on it, instead of a router. I'm using IPFire. If the processor supports AES-NI, the limiting factor will be your network speed, not the firewall's CPU. Finally, I've always felt that running a vpn on Qubes and having an always-on vpn running on a router/PC complement each other. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/KWSqbru--3-0%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Leak Problems with VPN ProxyVM + AirVPN & Network lock
13. Nov 2016 02:54 by tas...@openmailbox.org: > On 11/12/2016 05:47 PM, > hed...@tutanota.com> wrote: >> >> I guess the question still stands: is the latest version materially superior >> to the March 2015 version? (And enough to want to re-create over a dozen >> proxyVMs?) > > Yes, the VPN doc method is better in the sense that it separates packets > generated from the VPN VM from the packets going to/from appVMs. So > accidental net access generated while using the VPN CLI, for example, will be > blocked and stay out of the VPN tunnel. Its not critical but Whonix people > wanted it as a precaution. > > Chris > > Thanks for that. "Not critical" sounds like a good reason to stay with what I have for now, though I'll ensure that any new VPN proxyVMs I create use the new code. I might even lazily migrate them over one by one if I feel motivated enough to do so. And just to clarify, your github repo code is at https://github.com/tasket/Qubes-vpn-support . Correct? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/KWReL9J--3-0%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Leak Problems with VPN ProxyVM + AirVPN & Network lock
12. Nov 2016 20:39 by tas...@openmailbox.org: > > By 'template' you mean the setup at my github repo? If you look closely, they > are 90% the same except the doc version uses rc.local to start the client and > the one on github creates a systemd service for it. What makes it look > simpler is the github readme says 'download the file, unzip in /rw/config and > adjust the ovpn settings' and doesn't show script code. > > Chris No, it didn't come from github. After a brief search, I found the thread that was the source I used: https://groups.google.com/forum/#!msg/qubes-users/-9gR1Va3BnY/nQG6j-YOtZ4J;context-place=topic/qubes-users/T0wbCuIgISg which dates from March 2015. The author was cprise, so I was wrong to attribute it to Chris Laprise, though the names do seem suspiciously similar. ;) I guess the question still stands: is the latest version materially superior to the March 2015 version? (And enough to want to re-create over a dozen proxyVMs?) -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/KWPiIRQ--3-0%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Leak Problems with VPN ProxyVM + AirVPN & Network lock
11. Nov 2016 12:20 by sectesting0...@gmail.com: > I have successfully applied the setup and scripting in > > https://www.qubes-os.org/doc/vpn > > No more DNS leaks. > Quite some time ago I created a number of proxyVMs using the template supplied by (I think) Chris Laprise. The setup detailed in the Qubes docs, referred to above, is considerably more complex than the setup I'm running. Can anyone explain the advantages of the "new" proxyVM setup (ie the one described in the Qubes docs) compared to Chris's original template, and do people think it would be worth my while to update the dozen+ proxyVMs I currently have to the new format? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/KWOBiDy--3-0%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] R3.0 - R3.1: Upgrade of Debian TemplateVMs crashes
Summary of Problem: During a fresh installation of Qubes R3.1, all restored Debian TemplateVMs crash during the apt-get dist-upgrade and can no longer be restarted. Details: My preferred Qubes upgrade method is to do a fresh install to a new disk and backup/restore AppVMs and TemplateVMs from the previous version. This has highlighted two problems (the minor one first): 1. The documentation at https://www.qubes-os.org/doc/releases/3.1/release-notes/#upgrading details two upgrade methods: [quote]The easiest and safest way to upgrade to Qubes R3.1 is to install it fromscratch and use qubes backup and restore tools formigrating of all of the user VMs. Users of Qubes R3.0 can upgrade using experimentalprocedure.[/quote] I can find no reference in the fresh-installation instructions for upgrading the TemplateVMs, which only seems to be mentioned in the "experimental method" section. Perhaps the term "experimental" is no longer appropriate and, if so, should ideally be dropped. 2. After a fresh installation of R3.1, I restored all AppVMs, HVMs and TemplateVMs (from R3.0) to the new system, I upgraded the Fedora TemplateVMs without problem using the "experimental" procedure but ALL 3 of my Debian-based TemplateVMs crash during the apt-get dist-upgrade step, leaving the VMs in an unusable state (cannot be restarted). Since this is consistent across all three of my Debian-based TemplateVMs (debian-8, debian-8-nonfree and debian-8-sandbox) it seems likely to be a bug. Right now, I've restored all three from backup and they are still usable in R3.0 form but some things (eg VM Manager Update) no longer work. Is this a known problem? Is there a solution or workaround? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/KO6kF0M--3-0%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
