Re: [qubes-users] Qubes: Unable to connect to VPN

[Chris Laprise]

On 11/19/2018 01:09 AM, Chris Laprise wrote:

On 11/18/2018 07:36 PM, Otto Kratik wrote:
I realize it's possible to create a dedicated ProxyVM and use 
NetworkConfig to route VPN traffic, but that's not what I'm asking about.


In Qubes 3.2 from any standard Debian AppVM connected to Sys-Net I am 
able to simply do from terminal:


sudo openvpn --config 

..and it connects, and from then on all traffic from that AppVM is 
correctly routed through the VPN, as evidenced by testing IP address 
from web browser etc.


That approach might not work for DNS, however. Your DNS packets may be 
leaking through to your regular ISP. There is also no failsafe to 
prevent data leakage if openvpn for some reason decides to terminate.





In Qubes 4, this does not seem to work. The same command from AppVM 
terminal works fine and reports successful connection to the VPN, but 
from that point all attempts to connect to any website or other remote 
host fail completely and just time out. As soon as I terminate the VPN 
by pressing ctrl-c from terminal, net connectivity resumes as normal.


What has changed in Qubes 4, and what do I need to do different to 
make it work?


The Qubes VPN doc has two methods for correct openvpn configuration:

https://www.qubes-os.org/doc/vpn/

A better method is located here:

https://github.com/tasket/Qubes-vpn-support/

The difference is more failsafe checks and much smoother setup & operation.


For your specific question re: running openvpn in AppVMs, you may need 
to set the openvpn --verb level to 3 and look at the status messages. 
That will show you what routing commands openvpn is issuing 
(unfortunately it can vary a lot for different VPN services).


I would also try pinging known IP addresses (after connecting) to see if 
you can get a response. If you can, then the problem is likely with the 
DNS routing and dnat in the firewall.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/5e6d82d6-3c06-61bf-36da-31da74b84c6b%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes: Unable to connect to VPN

[Chris Laprise]

On 11/18/2018 07:36 PM, Otto Kratik wrote:

I realize it's possible to create a dedicated ProxyVM and use NetworkConfig to 
route VPN traffic, but that's not what I'm asking about.

In Qubes 3.2 from any standard Debian AppVM connected to Sys-Net I am able to 
simply do from terminal:

sudo openvpn --config 

..and it connects, and from then on all traffic from that AppVM is correctly 
routed through the VPN, as evidenced by testing IP address from web browser etc.


That approach might not work for DNS, however. Your DNS packets may be 
leaking through to your regular ISP. There is also no failsafe to 
prevent data leakage if openvpn for some reason decides to terminate.





In Qubes 4, this does not seem to work. The same command from AppVM terminal 
works fine and reports successful connection to the VPN, but from that point 
all attempts to connect to any website or other remote host fail completely and 
just time out. As soon as I terminate the VPN by pressing ctrl-c from terminal, 
net connectivity resumes as normal.

What has changed in Qubes 4, and what do I need to do different to make it work?


The Qubes VPN doc has two methods for correct openvpn configuration:

https://www.qubes-os.org/doc/vpn/

A better method is located here:

https://github.com/tasket/Qubes-vpn-support/

The difference is more failsafe checks and much smoother setup & operation.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/78e19f42-3600-4a68-018b-1753c143987e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] debian-based templates (and whonix) ignore dom0 keyboard language in 4.0.1 but not 4.0

[ryangreen]

I'm pretty sure this is a bug (linked below), but am posting here just in case 
there might be something I am missing:
https://github.com/QubesOS/updates-status/issues/791 

I set the language/keymap settings via localectl as recommended, as well as in 
the VMs themselves, but the debian-9 and whonix VMs default to english querty 
still. Removing those and installing the 4.0 templates in the 4.0.1 host 
demonstrates expected inheritance of settings as it should. I could not even 
find a way besides a startup script to set keyboard settings in the VMs (even 
/etc/default/keyboard in the VMs was ignored by the templates). Fedora-29 
templates seem to be fine. Any ideas? 

Thanks!
Ryan

-- 
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/LRdsNbs--3-1%40tuta.io.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes: Unable to connect to VPN

[Otto Kratik]

I realize it's possible to create a dedicated ProxyVM and use NetworkConfig to 
route VPN traffic, but that's not what I'm asking about. 

In Qubes 3.2 from any standard Debian AppVM connected to Sys-Net I am able to 
simply do from terminal:

sudo openvpn --config 

..and it connects, and from then on all traffic from that AppVM is correctly 
routed through the VPN, as evidenced by testing IP address from web browser etc.

In Qubes 4, this does not seem to work. The same command from AppVM terminal 
works fine and reports successful connection to the VPN, but from that point 
all attempts to connect to any website or other remote host fail completely and 
just time out. As soon as I terminate the VPN by pressing ctrl-c from terminal, 
net connectivity resumes as normal.

What has changed in Qubes 4, and what do I need to do different to make it work?

-- 
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/6b4f93fe-f2b9-4f47-98a6-09674d593525%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 on Qubes 4

[alex . jones . 4416]

On Wednesday, August 8, 2018 at 1:37:53 PM UTC, rex mat wrote:
> After the manual install, I can boot, but ethernet can only be configured 
> from the terminal. That is still work in progress.
> You need to have an android-x86 build and check out the 7.1.2 version to 
> build a cd. I found the instruction on the web on the android-x86.org web 
> page. I recommend using the ubuntu 16.4 version mentioned as the preferred 
> build machine in a hope you avoid the pain I went through to do a build on 
> qubes. 
> 
> 
> 
> I did the following 2 changes:
> 
> 
> 
> 1. Changed 1 line in "init" inside initrd
> from:
> 
>     for device in ${ROOT:-/dev/[hmnsv][dmrv][0-9a-z]*}; do
> to:
> 
>     for device in ${ROOT:-/dev/[hmnsvx][dmrv][0-9a-z]*}; do
> That allows the XEN hard drive to be used at initialization
> 
> 
> 
> 2. I configured the kernel
> Below is the config (I hope, as I played afterwards to get a proper mouse, 
> with no avail). This config disabled a lot of things that need blobs and the 
> like to get it built:
> 
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.9.109 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_64_SMP=y
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_DEBUG_RODATA=y
> CONFIG_PGTABLE_LEVELS=4
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
> 
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION="-android-x86_64"
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="android_x86_64"
> CONFIG_SWAP=y
> # CONFIG_SYSVIPC is not set
> # CONFIG_POSIX_MQUEUE is not set
> CONFIG_CROSS_MEMORY_ATTACH=y
> # CONFIG_FHANDLE is not set
> # CONFIG_USELIB is not set
> CONFIG_AUDIT=y
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> CONFIG_AUDITSYSCALL=y
> CONFIG_AUDIT_WATCH=y
> CONFIG_AUDIT_TREE=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> # CONFIG_IRQ_DOMAIN_DEBUG is not set
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> 
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
> 
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
> # CONFIG_IRQ_TIME_ACCOUNTING is not set
> # CONFIG_SCHED_WALT is not set
> CONFIG_BSD_PROCESS_ACCT=y
> # CONFIG_BSD_PROCESS_ACCT_V3 is not set
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
> 
> #
> # RCU Subsystem
> #
> CONFIG_PREEMPT_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=17
> 

[qubes-users] How to Change Default Language Qubes 4

[Campbell]

On install I chose UK English with US Keyboard. For some reason upon 
installation Qubes set my laptop keyboard to UK, even though I chose US 
keyboard during installation.

My guess is that when Qubes set language to UK English it automatically set the 
keyboard to UK, despite what I entered at install.

How do I change the default language to US English, and will that fix my 
keyboard layout?

-- 
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/f91c45b3-98a2-4bbd-af3b-cebba8eed1e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: i3 wm package still in testing

[aaq via qubes-users]

lørdag den 17. november 2018 kl. 23.44.01 UTC+1 skrev Vasilis:
> Hi,
> 
> It seems that the i3 window manager has been in the testing repository for a
> while, and I don't see many bug reports or posts on the mailing lists with
> problems associated to the i3 window manager.
> 
> Anything else required to make this package stable or when it can be moved to
> the stable repository?

Hello!

What version of Qubes are you running?

I installed i3 directly through "sudo qubes-dom0-update i3" and that resolved 
fine. Even the patched settings too.

So it should be in stable already.

Regards

-- 
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/d1e9c3c0-950c-4986-857d-e9005a88e367%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0 +Debian9 with Chuckoo Sandbox on Virtualbox

[aaq via qubes-users]

lørdag den 17. november 2018 kl. 22.26.00 UTC+1 skrev Black Beard:
> Hey community,
> 
> i hope, that someone can help me by following probleme.
> 
> My main OS is Qubes 4.0. No Dual-boot or other stuff. Only Qubes 4.0 
> installed.
> 
> My target:
> 
> Install Chuckoo Sandbox in Virtualbox on Debian9

Hey!

To my knowledge, it is not possible to run Virtualbox in a PVH VM (i.e. any 
type of Qube).

You can create a HVM, but I don't know whether or not Virtualbox works in those.

I would recommend installing Windows directly in a HVM though. I believe that's 
the recommended way from the Qubes devs as well.

Full disclosure: I don't know what Cuckoo is or how it works.

Hope you can use this :)
Otherwise, maybe someone else can chime in!

Regards

-- 
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/f32c995f-8694-478c-a9d2-5ace268ffd5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re[2]: [qubes-users] Donation costs

[Achim Patzner]

On 17.11.2018 03:42:25, "taii...@gmx.com"  wrote:

Using alipay is super bad considering you would be supporting a country
that censors the internet and imprisons people for viewing the "wrong"
things.


Not using Alipay is worse; it's been the only way of getting your money 
back if a dealer on one of 10Cent's market places is not keeping his 
side. So using the accumulated cash there for something I want to use it 
for is a bad idea? Well, then... And yes, I will continue buying 
interesting stuff directly from China instead of getting it via USA and 
Amazon.


Crypto payments and cash in mail to trusted qubes people (with secret 
shoppers to help ensure honesty) are the least terrible option.


From my point of view on ecology: not. Besides throwing all your money 
towards China, too or where do you think is most crypto mining being 
done because there currently is no place you're paying less for the 
ecological damage right now. So while China's censorship is not 
threatening me right now, adding unnecessary carbon dioxide to my 
environment is.



Achim

--
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/em1e3bd25a-70a9-4f86-8870-ca8597b98372%40sir-face.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 3.2 whonix 14 connects to tor, but there is no connection

[Patrick Schleizer]

aaq via qubes-users:
> lørdag den 17. november 2018 kl. 17.01.02 UTC+1 skrev Patrick Schleizer:
>> Franz:
>>> I succesfully updated to whonix 14, when the VM start a message tells:
>>> "connected to tor" making me happy, But if I ping google I get:
>>>
>>> user@host:~$ ping google.com
>>> PING google.com (216.58.207.206) 56(84) bytes of data.
>>> >From 10.137.5.34 (10.137.5.34) icmp_seq=1 Destination Port Unreachable
>>> ping: sendmsg: Operation not permitted
>>>
>>>
>>> what may be wrong?
>>> Best
>>>
>>
>> ping is UDP. And Tor doesn't support UDP.
>>
>> https://www.whonix.org/wiki/Tor#UDP
> 
> Ping is ICMP, not UDP.
> https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
> 

Indeed however the basic point still stands - unsupported by Tor.

-- 
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/b664dcf2-a31c-0d19-f36a-49c1f212b17d%40whonix.org.
For more options, visit https://groups.google.com/d/optout.