Re: [qubes-users] With 4K monitor, if screen goes blank, mouse clicks don't work in VMs
On 2019-09-30 05:44, David Hobach wrote: > On 9/29/19 7:12 PM, 'Micah Lee' via qubes-users wrote: >> On 2019-09-24 18:21, Michael Siepmann wrote: >>> I've read and followed the instructions on >>> https://www.qubes-os.org/doc/gui-configuration/ but the problem I'm >>> having is different. Here's what happens: >>> >>> 1. I'm using VMs on a 4K monitor successfully, via DisplayPort. >>> >>> 2a. I have Dom0 screensaver set to Blank Screen Only and it blanks >>> after >>> the configured number of minutes >>> >>> OR 2b. I switch to using the laptop screen, then back to the 4K monitor >>> >>> OR 2c. The computer wakes from sleep while the 4K monitor is in power >>> saving mode. >>> >>> 3. I can no longer click the mouse in my VMs (though it seems as if >>> maybe all clicks register in a very small area at the top left). The >>> mouse works normally in dom0. >>> >>> 4. If I switch to the laptop internal screen it works fine there, >>> but if >>> I switch back to the 4K monitor it still doesn't work there. The only >>> way to get mouse clicking working in the VMs again is to shut down the >>> VM and restart it while using the 4K monitor. >>> >>> The same thing happens if the computer goes to sleep and when I wake it >>> up the monitor is in power saving mode. My current workaround is to >>> disable the screensaver, and remember to wake the monitor before waking >>> the computer, >>> >>> Is this a bug I should report? Has anyone else encountered this >>> behavior? >> >> I've encountered this bug (or a similar one) as well on a 4K monitor. It >> appears that the mouse clicks only register if they're within the top >> left width and height of the laptop resolution. >> >> A workaround I've discovered is just restarting your VMs while your 4K >> monitor is plugged in. If you start a VM with the monitor plugged in, it >> lets you click anyone on the monitor within that VM. > > You can also try to switch to a tty (e.g. Alt+Ctl+F2), wait a few > seconds and then go back (Alt+Ctl+F1). Works for me whenever I have > issues with external monitors. > Thank you! I will try that next time it happens. When I tried to replicate the problem just now, it didn't happen. -- 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/bf6c25b4-00dd-0a07-e21d-bc954ec81424%40TechDesignPsych.com. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] With 4K monitor, if screen goes blank, mouse clicks don't work in VMs
On 2019-09-29 11:12, 'Micah Lee' via qubes-users wrote: > On 2019-09-24 18:21, Michael Siepmann wrote: >> I've read and followed the instructions on >> https://www.qubes-os.org/doc/gui-configuration/ but the problem I'm >> having is different. Here's what happens: >> >> 1. I'm using VMs on a 4K monitor successfully, via DisplayPort. >> >> 2a. I have Dom0 screensaver set to Blank Screen Only and it blanks after >> the configured number of minutes >> >> OR 2b. I switch to using the laptop screen, then back to the 4K monitor >> >> OR 2c. The computer wakes from sleep while the 4K monitor is in power >> saving mode. >> >> 3. I can no longer click the mouse in my VMs (though it seems as if >> maybe all clicks register in a very small area at the top left). The >> mouse works normally in dom0. >> >> 4. If I switch to the laptop internal screen it works fine there, but if >> I switch back to the 4K monitor it still doesn't work there. The only >> way to get mouse clicking working in the VMs again is to shut down the >> VM and restart it while using the 4K monitor. >> >> The same thing happens if the computer goes to sleep and when I wake it >> up the monitor is in power saving mode. My current workaround is to >> disable the screensaver, and remember to wake the monitor before waking >> the computer, >> >> Is this a bug I should report? Has anyone else encountered this behavior? > I've encountered this bug (or a similar one) as well on a 4K monitor. It > appears that the mouse clicks only register if they're within the top > left width and height of the laptop resolution. > > A workaround I've discovered is just restarting your VMs while your 4K > monitor is plugged in. If you start a VM with the monitor plugged in, it > lets you click anyone on the monitor within that VM. Thank you! There is related discussion here <https://github.com/QubesOS/qubes-core-admin/pull/240> and here <https://github.com/QubesOS/qubes-issues/issues/4509> but the problem I've been having is that after starting a VM with the monitor plugged in, it will only continue to work as long as the monitor never goes blank, even from the screen saver, or from switching temporarily to just using the laptop screen, or from going into suspend mode and then waking up before the monitor has been woken from its power saving mode. However, today when I tried to replicate the problem it didn't happen. Hopefully that will continue! -- 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/8946547f-3cd8-355c-0191-3f31be1a7647%40MSiep.com. signature.asc Description: OpenPGP digital signature
[qubes-users] With 4K monitor, if screen goes blank, mouse clicks don't work in VMs
I've read and followed the instructions on https://www.qubes-os.org/doc/gui-configuration/ but the problem I'm having is different. Here's what happens: 1. I'm using VMs on a 4K monitor successfully, via DisplayPort. 2a. I have Dom0 screensaver set to Blank Screen Only and it blanks after the configured number of minutes OR 2b. I switch to using the laptop screen, then back to the 4K monitor OR 2c. The computer wakes from sleep while the 4K monitor is in power saving mode. 3. I can no longer click the mouse in my VMs (though it seems as if maybe all clicks register in a very small area at the top left). The mouse works normally in dom0. 4. If I switch to the laptop internal screen it works fine there, but if I switch back to the 4K monitor it still doesn't work there. The only way to get mouse clicking working in the VMs again is to shut down the VM and restart it while using the 4K monitor. The same thing happens if the computer goes to sleep and when I wake it up the monitor is in power saving mode. My current workaround is to disable the screensaver, and remember to wake the monitor before waking the computer, Is this a bug I should report? Has anyone else encountered this behavior? Thanks, Michael Siepmann -- 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/98857414-7568-8a64-b168-783d90fd9642%40TechDesignPsych.com. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: Spontaneous rebooting
On 4/19/19 12:45 AM, Jon deps wrote: > On 4/13/19 8:01 PM, Michael Siepmann wrote: >> >> On 4/13/19 12:28 PM, Chris wrote: >>> Hello Michael, >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Friday, April 12, 2019 3:24 PM, Michael Siepmann >>> wrote: >>> >>>> On 8/10/18 12:37 PM, Kelly Dean wrote: >>>> >>>>> Am I the only one having a problem with Qubes spontaneously >>>>> rebooting on Intel hardware? Only other reports I see are about >>>>> AMD problems, but I'm using an Intel Core i3. >>>>> >>>>> Happens every few weeks. Sometimes just 1 or 2 weeks, sometimes 5 >>>>> or 6. Got it on Qubes 3.2, and now 4.0 too (new installation, not >>>>> upgrade), multiple times. >>>>> >>>>> Unlikely to be a hardware problem. The system passed both >>>>> memtest86 and a multi-day mersenne prime stress test. And other >>>>> OSes tested on this hardware before I switched to Qubes, including >>>>> Debian and Windows, never had a problem. >>>>> >>>>> The rebooting seems completely random. No apparent trigger, and no >>>>> warning. Acts like an instant hard reset. Sometimes even when the >>>>> system is idle, and I haven't touched the console for hours. >>>>> >>>>> It's wearingly inevitable enough that I don't even bother >>>>> intentionally rebooting after system updates anymore, in order to >>>>> minimize how many reboots I have to deal with (setting my >>>>> workspace back up is an ordeal), because I know the system will >>>>> end up spontaneously rebooting a week or two later anyway. >>>>> >>>> I'm having this problem too. I hadn't had it for a while but in the >>>> past week or so it's happened a few times. I have a Lenovo ThinkPad >>>> T440p with Intel Core i7, and Qubes 4.0 which I keep updated. >>>> >>> >>> I had this problem which was due to Intel AMT Control being enabled in >>> the BIOS. Since turning this off my system has not rebooted. >>> >>> Regards, >>> >>> Chris >>> >>> - >>> Chris Willard >>> chris-houdeaah+1aqdljmjb2...@public.gmane.org >>> <mailto:chris-houdeaah+1aqdljmjb2...@public.gmane.org> >> >> >> Thanks for the suggestion, Chris. I appreciate it. I checked and Intel >> AMT was already disabled so I guess something else must be causing it in >> my case. >> >> > > and what does > #journalctl -r say if anything ? > In a dom0 terminal if I type "journalctl -r" I see a lot of info. Anything in particular I should look for? -- 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/c725a9e8-3151-af72-b688-5bb4e4b7bf45%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Spontaneous rebooting
On 4/18/19 2:30 AM, David Hobach wrote: > On 4/18/19 12:52 AM, Michael Siepmann wrote: >>> I dont see this on any machine, including long running desktops. >>> Is it possible that you are suffering from over-heating? That would >>> account for symptoms. >> >> I'm now monitoring temperatures with the "sensors" command in a dom0 >> terminal and although the problem hasn't yet happened again, the >> temperatures I'm seeing are often getting close to or even reaching >> "Critical": >> >> coretemp-isa- >> Adapter: ISA adapter >> Package id 0: +100.0°C (high = +84.0°C, crit = +100.0°C) >> Core 0: +99.0°C (high = +84.0°C, crit = +100.0°C) >> Core 1: +100.0°C (high = +84.0°C, crit = +100.0°C) >> >> acpitz-virtual-0 >> Adapter: Virtual device >> temp1: +99.0°C (crit = +200.0°C) >> >> thinkpad-isa- >> Adapter: ISA adapter >> fan1: 4788 RPM >> >> If over-heating is the cause, does that suggest a hardware problem, or >> is there something I can do to configure Qubes differently to stop it >> from getting so hot? >> > > That's not good. Usually CPUs shut down and cause a reboot as you > observed at 100-110 Celsius (CPUs may die at higher temperatures and > thus perform an emergency shutdown). > > Looks like you have a hardware issue with your CPU fan. Either > cleaning the CPU fan and replacing the thermal paste or replacing the > entire CPU fan is likely to solve your issue. Youtube videos are your > best friend there. > > I had similar syptoms in the past, replaced the fan and thermal paste > (apparently the seller had applied way too much) and went down to > 70-80 Celsius at maximum load. > Thank you! I will try cleaning it first and then replace it if needed. I have some thermal paste that came with my Raspberry Pi. -- 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/5b0089a7-e87c-a385-d8c9-10a152358bce%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Spontaneous rebooting
On 4/13/19 7:56 AM, unman wrote: > On Sat, Apr 13, 2019 at 08:36:19AM +0200, David Hobach wrote: >> On 4/12/19 5:24 PM, Michael Siepmann wrote: >>> On 8/10/18 12:37 PM, Kelly Dean wrote: >>> >>>> Am I the only one having a problem with Qubes spontaneously rebooting on >>>> Intel hardware? Only other reports I see are about AMD problems, but I'm >>>> using an Intel Core i3. >>>> >>>> Happens every few weeks. Sometimes just 1 or 2 weeks, sometimes 5 or 6. >>>> Got it on Qubes 3.2, and now 4.0 too (new installation, not upgrade), >>>> multiple times. >>>> >>>> Unlikely to be a hardware problem. The system passed both memtest86 and a >>>> multi-day mersenne prime stress test. And other OSes tested on this >>>> hardware before I switched to Qubes, including Debian and Windows, never >>>> had a problem. >>>> >>>> The rebooting seems completely random. No apparent trigger, and no >>>> warning. Acts like an instant hard reset. Sometimes even when the system >>>> is idle, and I haven't touched the console for hours. >>>> >>>> It's wearingly inevitable enough that I don't even bother intentionally >>>> rebooting after system updates anymore, in order to minimize how many >>>> reboots I have to deal with (setting my workspace back up is an ordeal), >>>> because I know the system will end up spontaneously rebooting a week or >>>> two later anyway. >>> I'm having this problem too. I hadn't had it for a while but in the past >>> week or so it's happened a few times. I have a Lenovo ThinkPad T440p >>> with Intel Core i7, and Qubes 4.0 which I keep updated. >> Same here, but only since 4.0 and since coreboot & ME-cleaner on a T530. >> >> I've always suspected that it's related to memory kills (there was an OOM >> issue on github), but there's absolutely nothing in the journal after such a >> "forced" reboot. >> > I dont see this on any machine, including long running desktops. > Is it possible that you are suffering from over-heating? That would > account for symptoms. I'm now monitoring temperatures with the "sensors" command in a dom0 terminal and although the problem hasn't yet happened again, the temperatures I'm seeing are often getting close to or even reaching "Critical": coretemp-isa- Adapter: ISA adapter Package id 0: +100.0°C (high = +84.0°C, crit = +100.0°C) Core 0: +99.0°C (high = +84.0°C, crit = +100.0°C) Core 1: +100.0°C (high = +84.0°C, crit = +100.0°C) acpitz-virtual-0 Adapter: Virtual device temp1: +99.0°C (crit = +200.0°C) thinkpad-isa- Adapter: ISA adapter fan1: 4788 RPM If over-heating is the cause, does that suggest a hardware problem, or is there something I can do to configure Qubes differently to stop it from getting so hot? Thanks! -- 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/5ed85497-3b60-757f-c74a-0b7cc20bb5bb%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Spontaneous rebooting
On 4/13/19 12:28 PM, Chris wrote: > Hello Michael, > > ‐‐‐ Original Message ‐‐‐ > On Friday, April 12, 2019 3:24 PM, Michael Siepmann > wrote: > >> On 8/10/18 12:37 PM, Kelly Dean wrote: >> >>> Am I the only one having a problem with Qubes spontaneously rebooting on >>> Intel hardware? Only other reports I see are about AMD problems, but I'm >>> using an Intel Core i3. >>> >>> Happens every few weeks. Sometimes just 1 or 2 weeks, sometimes 5 or 6. Got >>> it on Qubes 3.2, and now 4.0 too (new installation, not upgrade), multiple >>> times. >>> >>> Unlikely to be a hardware problem. The system passed both memtest86 and a >>> multi-day mersenne prime stress test. And other OSes tested on this >>> hardware before I switched to Qubes, including Debian and Windows, never >>> had a problem. >>> >>> The rebooting seems completely random. No apparent trigger, and no warning. >>> Acts like an instant hard reset. Sometimes even when the system is idle, >>> and I haven't touched the console for hours. >>> >>> It's wearingly inevitable enough that I don't even bother intentionally >>> rebooting after system updates anymore, in order to minimize how many >>> reboots I have to deal with (setting my workspace back up is an ordeal), >>> because I know the system will end up spontaneously rebooting a week or two >>> later anyway. >>> >> I'm having this problem too. I hadn't had it for a while but in the >> past week or so it's happened a few times. I have a Lenovo ThinkPad >> T440p with Intel Core i7, and Qubes 4.0 which I keep updated. >> > > I had this problem which was due to Intel AMT Control being enabled in > the BIOS. Since turning this off my system has not rebooted. > > Regards, > > Chris > > - > Chris Willard > ch...@meliser.co.uk <mailto:ch...@meliser.co.uk> Thanks for the suggestion, Chris. I appreciate it. I checked and Intel AMT was already disabled so I guess something else must be causing it in my case. -- 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/c95ae02f-9981-3306-82c5-c7f83b13329e%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Spontaneous rebooting
On 8/10/18 12:37 PM, Kelly Dean wrote: > Am I the only one having a problem with Qubes spontaneously rebooting on > Intel hardware? Only other reports I see are about AMD problems, but I'm > using an Intel Core i3. > > Happens every few weeks. Sometimes just 1 or 2 weeks, sometimes 5 or 6. Got > it on Qubes 3.2, and now 4.0 too (new installation, not upgrade), multiple > times. > > Unlikely to be a hardware problem. The system passed both memtest86 and a > multi-day mersenne prime stress test. And other OSes tested on this hardware > before I switched to Qubes, including Debian and Windows, never had a problem. > > The rebooting seems completely random. No apparent trigger, and no warning. > Acts like an instant hard reset. Sometimes even when the system is idle, and > I haven't touched the console for hours. > > It's wearingly inevitable enough that I don't even bother intentionally > rebooting after system updates anymore, in order to minimize how many reboots > I have to deal with (setting my workspace back up is an ordeal), because I > know the system will end up spontaneously rebooting a week or two later > anyway. I'm having this problem too. I hadn't had it for a while but in the past week or so it's happened a few times. I have a Lenovo ThinkPad T440p with Intel Core i7, and Qubes 4.0 which I keep updated. -- 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/396283ef-2d8f-7836-b114-8ff9065ff827%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: VPN Disconnects when Qubes goes to sleep (and does not reconnect when coming out of sleep)?
On 12/17/2017 08:33 AM, Chris Laprise wrote: > On 12/17/2017 09:45 AM, Michael Siepmann wrote: > >> Recently the "LINK IS UP" notification has been staying visible until I >> manually close it. At first it wasn't doing that. Are you seeing that >> too? Could a recent update have caused this? > > Yes, I'm seeing it again on fedora-26 but not debian-9. This has been > an off-and-on issue with notify-send over the years. > I tried changing the template for my sys-vpn to debian-9 but the VPN service didn't work. However, when I switched it back to fedora-25 (I'm not using 26 yet) the persistent notification issue was fixed! (When the issue was happening, btw, it was only with the "up" notifications, not the "down" ones.) -- 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/2a50762d-53d4-dcd1-84bf-8786c9042e47%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: VPN Disconnects when Qubes goes to sleep (and does not reconnect when coming out of sleep)?
On 12/03/2017 10:00 PM, Chris Laprise wrote: > On 12/03/2017 10:30 PM, Michael Siepmann wrote: >> On 12/02/2017 11:14 PM, Chris Laprise wrote: >>> Looking at openvpn entries in 'journalctl' can give you a better idea. >>> I've seen instances where openvpn versions starting with 2.4 have this >>> bad reaction to disconnection (which is what sleep/wake is in this >>> case); with openvpn 2.3 you could count on it to keep >>> going/re-connecting. But there may also be an issue with the way >>> Qubes/Xen are handling the virtual interfaces between VMs; the >>> symptoms remind me of basic networking problems many of us have >>> experienced with prior Qubes releases, where only VM restarts would >>> re-build inter-VM links correctly. >>> >>> But if there isn't a basic networking problem, moving to a >>> service-based config will be more robust and should keep openvpn >>> running. One way to do this is to have your rc.local script start >>> openvpn with systemd-run (and the right options), but I've already >>> created a project that uses a full systemd config to manage VPN >>> processes... >>> >>> https://github.com/tasket/Qubes-vpn-support >>> >>> Setup is much easier than the vpn doc, though it currently only works >>> with Qubes 3.2 which I'm guessing you're using. The usual 'systemctl >>> start/stop/status' commands give you control over the >>> qubes-vpn-handler.service that manages openvpn. >>> >> Thank you! So far this seems to be working fine, automatically >> reconnecting after resume. Any chance of getting this approach mentioned >> on https://www.qubes-os.org/doc/vpn ? > > Great! I think it could be linked in the revised doc once the Qubes > R4.0 issues are worked out. > Recently the "LINK IS UP" notification has been staying visible until I manually close it. At first it wasn't doing that. Are you seeing that too? Could a recent update have caused 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 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/a5af6b2d-3e0f-8bc7-d3a9-9b5c9a9a70cf%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Local network access when using ProxyVM as VPN gateway using iptables and CLI scripts?
On 11/21/2017 02:07 PM, Michael Siepmann wrote: Michael Siepmann, Ph.D. *The Tech Design Psychologist*™ /Shaping technology to help people flourish/™ 303-835-0501 TechDesignPsych.com <http://www.TechDesignPsych.com?id=esig> OpenPGP: 6D65A4F7 <http://pool.sks-keyservers.net/pks/lookup?search=0x6D65A4F7&fingerprint=on&hash=on&op=vindex> > On 11/16/2017 09:50 PM, Michael Siepmann wrote: >> On 11/16/2017 08:11 AM, Chris Laprise wrote: >>> On 11/15/2017 10:17 PM, Michael Siepmann wrote: >>>> I've followed the instructions to "Set up a ProxyVM as a VPN gateway >>>> using iptables and CLI scripts" at https://www.qubes-os.org/doc/vpn/ >>>> and it's working well so far but I need to be able to access my local >>>> network 192.168.x.x. That worked when I was connecting to the VPN >>>> with Network Manager in my NetVM. Is there a way to configure that >>>> when using a ProxyVM as a VPN gateway? I'm guessing I need to do >>>> something in /rw/config/qubes-firewall-user-script in my VPN ProxyVM >>>> to configure iptables to allow bypassing the VPN for 192.168.x.x but >>>> I'm not sure how to do that. Any help will be greatly appreciated! >>>> >>> Hi Michael, >>> >>> You're not the first to ask about LAN access via a VPN VM. Various >>> posters in qubes-users have found ways around the anti-leak >>> configuration to access particular nets directly. >>> >>> What I usually advise is to think of VPN proxy, sys-firewall or any >>> other proxyVM as Qubes network primitives: Let the VPN VM do its thing >>> in guarding against non-tunnel access, and use sys-firewall or >>> specific proxyVM to access the LAN. This implies that any given appVM >>> can have access to only one type of network (or, only one type at a >>> time). This IMHO is the best way. >>> >>> OTOH, yes you can make the compromise in the VPN VM and allow >>> non-tunnel traffic. In the firewall script, you can start by >>> commenting-out these two lines: >>> >>> iptables -I FORWARD -o eth0 -j DROP >>> iptables -I FORWARD -i eth0 -j DROP >>> >>> This removes almost all leak protection, but should suffice for >>> initial testing. You may also have to add a route pointing to your >>> local net (see Linux "ip route" documentation) because the VPN may >>> have added its route as a default. If you wish to eventually reinstate >>> the above anti-leak rules you can try adding exceptions after those >>> two (so they will be listed _first_ in the FORWARD chain), for instance: >>> >>> iptables -I FORWARD -o eth0 -d 192.168.0.0/16 -j ACCEPT >>> iptables -I FORWARD -i eth0 -s 192.168.0.0/16 -j ACCEPT >>> >>> A word of caution: Once you start modifying rules like this its easy >>> to make mistakes that compromise security, even if you generally know >>> what you're doing. That's one reason to use the Qubes-oriented net >>> security model I mentioned initially. Another reason is, of course, >>> that even creating correct exceptions to tunnel enforcement opens you >>> up to certain kinds of threats. If your use case does not call for an >>> appVM accessing both VPN and LAN at the same time then there should be >>> no reason to make the compromise. >>> >> Hi Chris, >> >> Thank you! I will try this and report back. My main use case here is >> automatically doing an encrypted backup (with Borg Backup) of my files >> once an hour to a NAS device, which in turn automatically copies the >> backups to cloud storage at night, when I don't have competing needs for >> the upload bandwidth. Another use case is file sync, e.g. with SyncThing >> (which can work over the Internet, but much slower of course). However, >> I can certainly see the security advantages of only letting an appVM >> have access to one type of network, or only one type at a time. > Hi Chris, > > I got it working! The changes I've made (to allow access only to > 192.168.9.x, not 192.168.x.x) are: > > In my "sys-vpn" VPN Proxy VM... > > ...added the following lines to /rw/config/qubes-firewall-user-script, > after the "Block forwarding of connections through upstream network > device (in case the tunnel breaks)" section: > > # Allow forwarding of connections through upstream network device > # if they're to 192.168.9.x > iptables -I FORWARD -o eth0 -d 192.168.9.0/24 -j ACCEPT > iptables -I FORWARD -i
Re: [qubes-users] Re: VPN Disconnects when Qubes goes to sleep (and does not reconnect when coming out of sleep)?
On 12/02/2017 11:14 PM, Chris Laprise wrote: > On 12/03/2017 12:09 AM, Michael Siepmann wrote: >> On 11/30/2017 10:14 PM, Chris Laprise wrote: >>> On 11/30/2017 11:44 PM, Michael Siepmann wrote: >>>> >>>> On Jun 12, 2017, Andrew Morgan wrote: >>>> >>>>> Did you follow the "Set up a ProxyVM as a VPN gateway using >>>>> iptables and >>>>> CLI scripts" section of the Qubes VPN docs >>>>> (https://www.qubes-os.org/doc/vpn/ >>>>> <https://www.qubes-os.org/doc/vpn/> )? >>>>> >>>>> If so you should be good just to execute the `/rw/config/rc.local` >>>>> file >>>>> on your VPN VM after every suspend either manually, through a >>>>> keyboard >>>>> shortcut (which I do personally with the following command): >>>>> >>>>> qvm-run -i root sys-vpn "/rw/config/rc.local" >>>> >>>> I followed the "Set up a ProxyVM as a VPN gateway using iptables >>>> and CLI scripts" instructions but for me executing >>>> "/rw/config/rc.local" doesn't make it work again. >>>> >>>> I've also tried commenting out or deleting "persist tun" from my >>>> OpenVPN config file, as Chris Laprise as suggested in the thread >>>> "is vpn made manually, not supposed to restart after suspend?" on >>>> May 21 but that isn't helping either. >>>> >>>> My current workaround is a script I wrote in dom0 that first does >>>> "qvm-prefs VMname -s netvm none" for all the VMs I normally have >>>> running that use sys-vpn (my ProxyVM VPN gateway), then shuts >>>> sys-vpn down, waits 10 seconds, starts sys-vpn, then does >>>> "qvm-prefs VMname -s netvm sys-vpn" for all those VMs. >>>> >>>> Any ideas what could be going on so that neither executing >>>> /rw/config/rc.local nor commenting out "persist tun" works in my case? >>>> >>> >>> I have a couple ideas as to workarounds. Instead of re-starting >>> sys-vpn, you could: >>> >>> qvm-run -u root sys-vpn 'pkill openvpn' >>> qvm-run -u root sys-vpn 'sh /rw/config/rc.local' >>> >>> ...before you re-enable the netvm prefs. >>> >>> Also, one thing that changing the netvm prefs does is to trigger >>> qubes-firewall-user-script to run again. You might compare the state >>> of iptables before and after your workaround to see if something >>> went missing after waking from sleep. If that's the case, you could >>> just trigger the script as a third command added to the above. >>> >> >> Thanks! I tried those commands and they don't get it working again. I >> still have to shut it down and restart it. I also checked the >> iptables and that does not seem not to be the problem. However, I've >> found out that after a brief suspend the VPN may continue working, >> but in cases when it stops working, the process ends and can't be >> restarted. In the following the first ps command was just after >> resuming, and the second a few seconds later, after I'd seen the "VPN >> is down" notification: >> >> [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep >> -v grep" >> 5 S root 1093 1 0 80 0 - 16371 poll_s 14:33 ? >> 00:00:42 openvpn --cd /rw/config/vpn/ --config openvpn-client.ovpn >> --daemon >> [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep >> -v grep" >> [user@sys-vpn ~]$ >> [user@sys-vpn ~]$ sudo sh /rw/config/rc.local >> [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep >> -v grep" >> [user@sys-vpn ~]$ >> >> I also tried "pkill openvpn" when it is working, and I can't restart >> it after that either: >> >> [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep >> -v grep" >> 5 S root 1134 1 0 80 0 - 16371 poll_s 21:26 ? >> 00:00:00 openvpn --cd /rw/config/vpn/ --config openvpn-client.ovpn >> --daemon >> [user@sys-vpn ~]$ sudo sg qvpn -c "pkill openvpn" >> [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep >> -v grep" >> [user@sys-vpn ~]$ sudo sh /rw/config/rc.local >> [user@sys-vpn ~]$ sudo sg qvpn -c "ps
Re: [qubes-users] Re: VPN Disconnects when Qubes goes to sleep (and does not reconnect when coming out of sleep)?
On 11/30/2017 10:14 PM, Chris Laprise wrote: > On 11/30/2017 11:44 PM, Michael Siepmann wrote: >> >> On Jun 12, 2017, Andrew Morgan wrote: >> >>> Did you follow the "Set up a ProxyVM as a VPN gateway using iptables >>> and >>> CLI scripts" section of the Qubes VPN docs >>> (https://www.qubes-os.org/doc/vpn/ >>> <https://www.qubes-os.org/doc/vpn/> )? >>> >>> If so you should be good just to execute the `/rw/config/rc.local` file >>> on your VPN VM after every suspend either manually, through a keyboard >>> shortcut (which I do personally with the following command): >>> >>> qvm-run -i root sys-vpn "/rw/config/rc.local" >> >> I followed the "Set up a ProxyVM as a VPN gateway using iptables and >> CLI scripts" instructions but for me executing "/rw/config/rc.local" >> doesn't make it work again. >> >> I've also tried commenting out or deleting "persist tun" from my >> OpenVPN config file, as Chris Laprise as suggested in the thread "is >> vpn made manually, not supposed to restart after suspend?" on May 21 >> but that isn't helping either. >> >> My current workaround is a script I wrote in dom0 that first does >> "qvm-prefs VMname -s netvm none" for all the VMs I normally have >> running that use sys-vpn (my ProxyVM VPN gateway), then shuts sys-vpn >> down, waits 10 seconds, starts sys-vpn, then does "qvm-prefs VMname >> -s netvm sys-vpn" for all those VMs. >> >> Any ideas what could be going on so that neither executing >> /rw/config/rc.local nor commenting out "persist tun" works in my case? >> > > I have a couple ideas as to workarounds. Instead of re-starting > sys-vpn, you could: > > qvm-run -u root sys-vpn 'pkill openvpn' > qvm-run -u root sys-vpn 'sh /rw/config/rc.local' > > ...before you re-enable the netvm prefs. > > Also, one thing that changing the netvm prefs does is to trigger > qubes-firewall-user-script to run again. You might compare the state > of iptables before and after your workaround to see if something went > missing after waking from sleep. If that's the case, you could just > trigger the script as a third command added to the above. > Thanks! I tried those commands and they don't get it working again. I still have to shut it down and restart it. I also checked the iptables and that does not seem not to be the problem. However, I've found out that after a brief suspend the VPN may continue working, but in cases when it stops working, the process ends and can't be restarted. In the following the first ps command was just after resuming, and the second a few seconds later, after I'd seen the "VPN is down" notification: [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep" 5 S root 1093 1 0 80 0 - 16371 poll_s 14:33 ?00:00:42 openvpn --cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep" [user@sys-vpn ~]$ [user@sys-vpn ~]$ sudo sh /rw/config/rc.local [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep" [user@sys-vpn ~]$ I also tried "pkill openvpn" when it is working, and I can't restart it after that either: [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep" 5 S root 1134 1 0 80 0 - 16371 poll_s 21:26 ? 00:00:00 openvpn --cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon [user@sys-vpn ~]$ sudo sg qvpn -c "pkill openvpn" [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep" [user@sys-vpn ~]$ sudo sh /rw/config/rc.local [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep" [user@sys-vpn ~]$ Any ideas why this might be happening? -- 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/c8b6143e-0fa7-f04a-c03f-d6a5d95bf0a3%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: VPN Disconnects when Qubes goes to sleep (and does not reconnect when coming out of sleep)?
On Jun 12, 2017, Andrew Morgan wrote: > Did you follow the "Set up a ProxyVM as a VPN gateway using iptables and > CLI scripts" section of the Qubes VPN docs > (https://www.qubes-os.org/doc/vpn/ <https://www.qubes-os.org/doc/vpn/> )? > > If so you should be good just to execute the `/rw/config/rc.local` file > on your VPN VM after every suspend either manually, through a keyboard > shortcut (which I do personally with the following command): > > qvm-run -i root sys-vpn "/rw/config/rc.local" I followed the "Set up a ProxyVM as a VPN gateway using iptables and CLI scripts" instructions but for me executing "/rw/config/rc.local" doesn't make it work again. I've also tried commenting out or deleting "persist tun" from my OpenVPN config file, as Chris Laprise as suggested in the thread "is vpn made manually, not supposed to restart after suspend?" on May 21 but that isn't helping either. My current workaround is a script I wrote in dom0 that first does "qvm-prefs VMname -s netvm none" for all the VMs I normally have running that use sys-vpn (my ProxyVM VPN gateway), then shuts sys-vpn down, waits 10 seconds, starts sys-vpn, then does "qvm-prefs VMname -s netvm sys-vpn" for all those VMs. Any ideas what could be going on so that neither executing /rw/config/rc.local nor commenting out "persist tun" works in my case? Thanks! Michael Siepmann -- Michael Siepmann, Ph.D. *The Tech Design Psychologist*™ /Shaping technology to help people flourish/™ 303-835-0501 TechDesignPsych.com <http://www.TechDesignPsych.com?id=esig> OpenPGP: 6D65A4F7 <http://pool.sks-keyservers.net/pks/lookup?search=0x6D65A4F7&fingerprint=on&hash=on&op=vindex> -- 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/8829c4c7-3d0e-267d-e384-00e4b495301e%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Local network access when using ProxyVM as VPN gateway using iptables and CLI scripts?
On 11/16/2017 09:50 PM, Michael Siepmann wrote: > On 11/16/2017 08:11 AM, Chris Laprise wrote: >> On 11/15/2017 10:17 PM, Michael Siepmann wrote: >>> I've followed the instructions to "Set up a ProxyVM as a VPN gateway >>> using iptables and CLI scripts" at https://www.qubes-os.org/doc/vpn/ >>> and it's working well so far but I need to be able to access my local >>> network 192.168.x.x. That worked when I was connecting to the VPN >>> with Network Manager in my NetVM. Is there a way to configure that >>> when using a ProxyVM as a VPN gateway? I'm guessing I need to do >>> something in /rw/config/qubes-firewall-user-script in my VPN ProxyVM >>> to configure iptables to allow bypassing the VPN for 192.168.x.x but >>> I'm not sure how to do that. Any help will be greatly appreciated! >>> >> Hi Michael, >> >> You're not the first to ask about LAN access via a VPN VM. Various >> posters in qubes-users have found ways around the anti-leak >> configuration to access particular nets directly. >> >> What I usually advise is to think of VPN proxy, sys-firewall or any >> other proxyVM as Qubes network primitives: Let the VPN VM do its thing >> in guarding against non-tunnel access, and use sys-firewall or >> specific proxyVM to access the LAN. This implies that any given appVM >> can have access to only one type of network (or, only one type at a >> time). This IMHO is the best way. >> >> OTOH, yes you can make the compromise in the VPN VM and allow >> non-tunnel traffic. In the firewall script, you can start by >> commenting-out these two lines: >> >> iptables -I FORWARD -o eth0 -j DROP >> iptables -I FORWARD -i eth0 -j DROP >> >> This removes almost all leak protection, but should suffice for >> initial testing. You may also have to add a route pointing to your >> local net (see Linux "ip route" documentation) because the VPN may >> have added its route as a default. If you wish to eventually reinstate >> the above anti-leak rules you can try adding exceptions after those >> two (so they will be listed _first_ in the FORWARD chain), for instance: >> >> iptables -I FORWARD -o eth0 -d 192.168.0.0/16 -j ACCEPT >> iptables -I FORWARD -i eth0 -s 192.168.0.0/16 -j ACCEPT >> >> A word of caution: Once you start modifying rules like this its easy >> to make mistakes that compromise security, even if you generally know >> what you're doing. That's one reason to use the Qubes-oriented net >> security model I mentioned initially. Another reason is, of course, >> that even creating correct exceptions to tunnel enforcement opens you >> up to certain kinds of threats. If your use case does not call for an >> appVM accessing both VPN and LAN at the same time then there should be >> no reason to make the compromise. >> > Hi Chris, > > Thank you! I will try this and report back. My main use case here is > automatically doing an encrypted backup (with Borg Backup) of my files > once an hour to a NAS device, which in turn automatically copies the > backups to cloud storage at night, when I don't have competing needs for > the upload bandwidth. Another use case is file sync, e.g. with SyncThing > (which can work over the Internet, but much slower of course). However, > I can certainly see the security advantages of only letting an appVM > have access to one type of network, or only one type at a time. Hi Chris, I got it working! The changes I've made (to allow access only to 192.168.9.x, not 192.168.x.x) are: In my "sys-vpn" VPN Proxy VM... ...added the following lines to /rw/config/qubes-firewall-user-script, after the "Block forwarding of connections through upstream network device (in case the tunnel breaks)" section: # Allow forwarding of connections through upstream network device # if they're to 192.168.9.x iptables -I FORWARD -o eth0 -d 192.168.9.0/24 -j ACCEPT iptables -I FORWARD -i eth0 -s 192.168.9.0/24 -j ACCEPT ...added the following lines to /rw/config/vpn/qubes-vpn-handler.sh, at the end of the "up)" case: # Allow access to home network for backup, etc. ip route add 192.168.9.0/24 via 10.137.1.1 dev eth0 ...where 10.137.1.1 is the gateway for my "sys-vpn" VPN ProxyVM. Please let me know if you see any problems with what I've done other than the general security caveat you mentioned before. Many thanks for your help! I really appreciate it. -- 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/1f12b2c7-17b6-69a3-44fb-b6f247dc3f84%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Local network access when using ProxyVM as VPN gateway using iptables and CLI scripts?
On 11/16/2017 08:11 AM, Chris Laprise wrote: > On 11/15/2017 10:17 PM, Michael Siepmann wrote: >> >> I've followed the instructions to "Set up a ProxyVM as a VPN gateway >> using iptables and CLI scripts" at https://www.qubes-os.org/doc/vpn/ >> and it's working well so far but I need to be able to access my local >> network 192.168.x.x. That worked when I was connecting to the VPN >> with Network Manager in my NetVM. Is there a way to configure that >> when using a ProxyVM as a VPN gateway? I'm guessing I need to do >> something in /rw/config/qubes-firewall-user-script in my VPN ProxyVM >> to configure iptables to allow bypassing the VPN for 192.168.x.x but >> I'm not sure how to do that. Any help will be greatly appreciated! >> > > Hi Michael, > > You're not the first to ask about LAN access via a VPN VM. Various > posters in qubes-users have found ways around the anti-leak > configuration to access particular nets directly. > > What I usually advise is to think of VPN proxy, sys-firewall or any > other proxyVM as Qubes network primitives: Let the VPN VM do its thing > in guarding against non-tunnel access, and use sys-firewall or > specific proxyVM to access the LAN. This implies that any given appVM > can have access to only one type of network (or, only one type at a > time). This IMHO is the best way. > > OTOH, yes you can make the compromise in the VPN VM and allow > non-tunnel traffic. In the firewall script, you can start by > commenting-out these two lines: > > iptables -I FORWARD -o eth0 -j DROP > iptables -I FORWARD -i eth0 -j DROP > > This removes almost all leak protection, but should suffice for > initial testing. You may also have to add a route pointing to your > local net (see Linux "ip route" documentation) because the VPN may > have added its route as a default. If you wish to eventually reinstate > the above anti-leak rules you can try adding exceptions after those > two (so they will be listed _first_ in the FORWARD chain), for instance: > > iptables -I FORWARD -o eth0 -d 192.168.0.0/16 -j ACCEPT > iptables -I FORWARD -i eth0 -s 192.168.0.0/16 -j ACCEPT > > A word of caution: Once you start modifying rules like this its easy > to make mistakes that compromise security, even if you generally know > what you're doing. That's one reason to use the Qubes-oriented net > security model I mentioned initially. Another reason is, of course, > that even creating correct exceptions to tunnel enforcement opens you > up to certain kinds of threats. If your use case does not call for an > appVM accessing both VPN and LAN at the same time then there should be > no reason to make the compromise. > Hi Chris, Thank you! I will try this and report back. My main use case here is automatically doing an encrypted backup (with Borg Backup) of my files once an hour to a NAS device, which in turn automatically copies the backups to cloud storage at night, when I don't have competing needs for the upload bandwidth. Another use case is file sync, e.g. with SyncThing (which can work over the Internet, but much slower of course). However, I can certainly see the security advantages of only letting an appVM have access to one type of network, or only one type at a time. -- 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/e80071ff-f740-4de7-25a1-89ddf0798647%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] Local network access when using ProxyVM as VPN gateway using iptables and CLI scripts?
I've followed the instructions to "Set up a ProxyVM as a VPN gateway using iptables and CLI scripts" at https://www.qubes-os.org/doc/vpn/ and it's working well so far but I need to be able to access my local network 192.168.x.x. That worked when I was connecting to the VPN with Network Manager in my NetVM. Is there a way to configure that when using a ProxyVM as a VPN gateway? I'm guessing I need to do something in /rw/config/qubes-firewall-user-script in my VPN ProxyVM to configure iptables to allow bypassing the VPN for 192.168.x.x but I'm not sure how to do that. Any help will be greatly appreciated! Best regards, Michael Siepmann -- Michael Siepmann, Ph.D. *The Tech Design Psychologist*™ /Shaping technology to help people flourish/™ 303-835-0501 TechDesignPsych.com <http://www.TechDesignPsych.com?id=esig> OpenPGP: 6D65A4F7 <http://pool.sks-keyservers.net/pks/lookup?search=0x6D65A4F7&fingerprint=on&hash=on&op=vindex> -- 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/5f3a27e0-43e1-8a4a-11e1-b3b834b38037%40TechDesignPsych.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
