Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
Perfect. Sound good to me. I'm going to quickly run through your checklist first to re-verify everything then I'll get on the IRC. I've never been on either but I'll send a quick update here when I've got it going. -- 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/008a3242-3d05-48a1-b4c6-a4bcafb99e98%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Issues with https certificate for Fedora yum repo
The short version is, the certificate for the https URL listed in /etc/yum.repos.d/qubes-r4.repo is throwing the below error, and browsing to the same URL returns an invalid certificate. URL: https://yum.qubes-os.org/r4.0/current/vm/ The certificate expired earlier today, approximately 6 hours ago I believe. It is a lets encrypt certificate. The error from running: 'sudo yum upgrade' is: 'Error: Failed to synchronize cache for repo 'qubes-vm-r4.0-current' Certificate info is: Fingerprint: 04:34:6A:84:D9:A9:3C:EF:E7:BD:03:D2:24:DA:CC:84:06:70 Issuer: CN = Let's Encrypt Authority X3 O = Let's Encrypt C = US Validity: Not Before: (September 26, 2018, 11:27:47 PM GMT) Not After: (December 25, 2018, 11:27:47 PM GMT) A side question, What is the better chat service to use. I was trying OFTC IRC and riseup.net XMPP. Jason -- 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/2b5d05948e8168f804deea8ea1c17c50%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
OGBaby: > Hey Qubenix, I have an update for you and anyone curious. The MDB_BAD_TXN > error has been resolved. For anyone wondering this error most likely mean > your blockchain was interrupted during sync and is now corrupt. > > The solution advised by Monero channels is to delete the blockchain data > ("lmdb") amd resync. > > I was recommended to include the flag '--db-sync-mode=safe' to monerod upon > startup to protect against unexpected interruptions or reboots during sync. > > You should be able to locate the blockchain within /home/user/.bitmonero/ > > Keep in mind .bitmonero is a hidden directory. > > After the resync everything regarding the daemon seem to be in place and > running. I will repost the most recent logs and provide fresh ones as well. > > I am being redirected back here since that particular monerod error appear to > be resolved, there may be a minor issue with the separation setup of wallet > and daemon VMs. The lower-left Network Status is 'disconnected' and of course > "Wallet is not connected to daemon" is still visible above. > > If there is anything specific I should verify and confirm, I would gladly > take a look. > > Thanks everyone > > Monerod status (previous) > https://pastebin.com/v95gn1aB > > Monerod Bitmonero.log (previous) > https://pastebin.com/3mzhuSHt > > Monerod Status (fresh) > https://pastebin.com/XwAy91dh > > Monerod Bitmonero.log (fresh) > https://pastebin.com/CHSHg9Zz > > > Hopefully it's just something I'm overlooking. > Your daemon issues seem solved, so that's a step in the right direction. Can you come on irc to resolve this (either freenode or oftc)? I suspect we're going to be doing a lot of back and forth to find out which step in the guide wasn't completed correctly. If you want to, you can go back through the guide first and pay special attention that you have done the following correctly: 1. Set up qrexec policy (/etc/qubes-rpc/policy/whonix.monerod-mainnet) in dom0. Guide section 1.4. 2. Set up qrexec file (/rw/usrlocal/etc/qubes-rpc/whonix.monerod-mainnet) on the daemon vm. Guide section 3.2. 3. Set up /rw/config/rc.local on wallet vm. Guide section 4.2. If all of that is done correct, the gui is set to use a local node, and you still have no connection then we will need to do a lot of back and forth with running commands in vms and telling me the output. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/86c93f8b-5a4c-4c83-a521-79e708c54e6c%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
Hey Qubenix, I have an update for you and anyone curious. The MDB_BAD_TXN error has been resolved. For anyone wondering this error most likely mean your blockchain was interrupted during sync and is now corrupt. The solution advised by Monero channels is to delete the blockchain data ("lmdb") amd resync. I was recommended to include the flag '--db-sync-mode=safe' to monerod upon startup to protect against unexpected interruptions or reboots during sync. You should be able to locate the blockchain within /home/user/.bitmonero/ Keep in mind .bitmonero is a hidden directory. After the resync everything regarding the daemon seem to be in place and running. I will repost the most recent logs and provide fresh ones as well. I am being redirected back here since that particular monerod error appear to be resolved, there may be a minor issue with the separation setup of wallet and daemon VMs. The lower-left Network Status is 'disconnected' and of course "Wallet is not connected to daemon" is still visible above. If there is anything specific I should verify and confirm, I would gladly take a look. Thanks everyone Monerod status (previous) https://pastebin.com/v95gn1aB Monerod Bitmonero.log (previous) https://pastebin.com/3mzhuSHt Monerod Status (fresh) https://pastebin.com/XwAy91dh Monerod Bitmonero.log (fresh) https://pastebin.com/CHSHg9Zz Hopefully it's just something I'm overlooking. -- 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/acef13dc-6dda-4a96-bf97-9a7917f06fed%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] 4.0rc2 is not the same as 4.0.1-rc2.
I see several posts citing 4.0rc2 when it is clear from context that they are talking about 4.0.1-rc2. They are completely different releases. Take care to cite the correct release in your 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 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/9e5aa214-d164-4ebe-aee6-ab7c80331898%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Split gpg is just too cool.
U2F Proxy is not so cool. So far no joy getting it to work. Someone on reddit had similar issues and questions and resolved by installing USB keyboard support. That’s not mentioned in the Qubes docs and I hope we don’t have to resort to that. If that were a requirement, surely the docs would have mentioned 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/ae2f8918-4485-4a94-b812-17d3ecdae544%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Newb Help with Installation
I install from USB3 stick all the time and it’s fast. Even if it is dropping back to 2.0, it should not be as slow as you describe. -- 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/8357b8f1-4d4b-405c-9074-e5d2cb24892a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Newb Help with Installation
I would be more concerned about security than drivers. I connected a Caldigit Plus TB3 hub to my Qubes laptop and it worked fine, but now I had a new threat vector since TB has direct access to the PCI bus. As someone else here noted, there may be a time when they vector is secure, but not yet. I promptly removed the TB3 dock after that. -- 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/026a0361-b0e9-461e-9aa0-f644cd858067%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Broadcom brcm 4356 Wifi card not working
On Tue, Dec 25, 2018 at 04:22:32AM -0800, Martin Weck wrote: > Hi, > I have got a Lenovo L460 with Broadcom brcm4356 Wifi Adapter that I don't get > working on Qubes. > To isolate the problem, I have first installed a debian-9 directly on the > machine and got this after some problems working > (https://www.linuxquestions.org/questions/linux-wireless-networking-41/debian-broadcom-bcm4356-802-11ac-wireless-not-working-4175644801/) > > Steps to reproduce: > - Have Qubes 3.2.1 (also tried Qubes 4.0.1-rc2 without success) > - Create NetVM debian-9 based with device: > -- 00:1f.6 Ethernet controller: Intel Corporation l219-LM (rev21) > -- 03:00.0 Network controller: Broadcom Limited BCM4356 802.11ac Wireless > Network Adapter (rev02) > (cable based Ethernet works on qube without flaws) > - install firmware-brcm80211_20180825+dfsg-1_all.deb and add > brcmfmac4356-pcie.txt > - Unload kernel module sudo modprobe -f brcmfmac > - Load kernel module sudo modprobe brcmfmac > - sudo dmesg | less > [3.476763] usbcore: registered new interface driver brcmfmac > [3.532479] e1000e :00:00.6 eth0: (PCI Express:2.5GT/s:Width x1) > c8:5b:76:5c:5a:06 > [3.532497] e1000e :00:00.6 eth0: Intel(R) PRO/1000 Network Connection > [3.532587] e1000e :00:00.6 eth0: MAC: 12, PHY: 12, PBA No: FF-0FF > [3.535156] brcmfmac :00:01.0: Xen PCI mapped GSI18 to IRQ28 > [3.537736] brcmfmac: brcmf_chip_recognition: SB chip is not supported > [3.537749] brcmfmac: brcmf_pcie_probe: failed 14e4:43ec > [3.539846] e1000e :00:00.6 enp0s0f6: renamed from eth0 > > - user@debian-net:/lib64$ sudo lspci -k > 00:00.6 Ethernet controller: Intel Corporation Ethernet Connection I219-LM > (rev 21) > Subsystem: Lenovo Ethernet Connection I219-LM > Kernel driver in use: e1000e > Kernel modules: e1000e > 00:01.0 Network controller: Broadcom Limited BCM4356 802.11ac Wireless > Network Adapter (rev 02) > Subsystem: Lenovo BCM4356 802.11ac Wireless Network Adapter > Kernel modules: brcmfmac > > user@debian-net:/lib64$ sudo ifconfig > enp0s0f6: flags=4163 mtu 1500 > inet 192.168.45.172 netmask 255.255.255.0 broadcast 192.168.45.255 > inet6 fe80::eacd:816d:b465:e28a prefixlen 64 scopeid 0x20 > ether c8:5b:76:5c:5a:06 txqueuelen 1000 (Ethernet) > RX packets 29359 bytes 35630763 (33.9 MiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 17109 bytes 1910984 (1.8 MiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > device interrupt 26 memory 0xe160-e162 > > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 1000 (Local Loopback) > RX packets 8 bytes 380 (380.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 8 bytes 380 (380.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > => if I install on the same machine debian-9 directly the wifi works > => if I use qubes debian-9 NetVM I get "SB chip is not supported" even though > device is attached to VM > => Has anyone an idea/suggestion what I could do to get rid of the "SB chip > is not supported"? I assumed I had the wrong firmware, but why can I use the > exact same *deb package on the same machine successfully if I install debian > directly on the same machine without qubes? > > P.S.: I have also tried to create a HVM with debian-9 installer: > - if I install debian on the HVM the X Window gets messed up => black screen > => need to switch on/off the machine > - if I use live DVD on HVM => I can install package until reboot, run the > modprobe brcmfmac command without error in dmesg, but the Wifi Adapter is not > shown in the Network Manager > > Thanks for any help! > That driver is quite buggy, and broadcom linux support is woeful. Try the driver from testing - search packages.debian.org, and look under testing for the latest version. It should install ok. -- 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/20181226003715.sbgoqbik5ltarfty%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: How risky is GPU pass-through?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Zrubi: > On 12/23/18 9:34 PM, Demi M. Obenour wrote: >> Someone I know is interested in using QubesOS. However, they >> are also a gamer: if they could not have a Windows VM with access >> to a dedicated graphics card for use by games, then QubesOS is >> not an option for them. > > Short answer: Qubes OS is not an option for them. > Why do you say that? If you search this list there are people that successfully game on Win vm with gpu passthrough. > > The risk part would come only after this feature exists in practice > ;) Search back for the details. > > I can't speak to the security risk from personal experience or knowledge, but I found this: https://security.stackexchange.com/questions/162122/gpu-passthrough-security/162175. - -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEElgluTKCHDxxbr33ZCdFZ4SQfnFQFAlwgMjdfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 MDk2RTRDQTA4NzBGMUM1QkFGN0REOTA5RDE1OUUxMjQxRjlDNTQACgkQCdFZ4SQf nFR7IA//YE7rVNDmYFiXmIU9v7d7j9Bg3bPNSQ6wFnWNclylA3NSvzJ2k/uurcXW HSz/7r3jDSnJgD6trVan8SMOLlVhU48Hz9FCOxrVagwU69Ch+70vEZplauDcbEC7 UKu3vTFaC5Gawu8EHSqeT97eYCjSqvc/K82g6Wlij9uYOp7juTpQXX9ekIYH4i94 2TI+ZEYCJ/IaoL12aNQbDz6TzR6lsQDnsUiEppd1hnCX/yQphVymRlFG4qBQsXUA 40cAiqSUvpoAchxiWuTS7o4wCblSgrYkHHNzBvX0i+8JhSVmiknloPb+rBZmUVrs 0AoS2cqW3ojKIDXdfQ5Yn27p9TSR9AkoGbNDN9hZSl0CQTjXDGKV/Lcdj9qSSy+X +xOEJL63nYp94hofsDmZhg7EfcARA5C5JbLF0TzA2fyXlO7hgoX/SsCAv+KaDWhE 8B3Sq+sWH7MAfiJOK/UZN52Bi+I5hUsYsdXPTDSxqkhc6aOnYL8i9wi89gPZ4iVi JTQ6Tzn87Y5fWeBnz10viMWyfj71rD1AktA9GM20zsw60jx+GcDwtxOHxQLWRTNb vR1KuET9E+XaS4oEmTcNDACNj0ui+H7OgCRt64plfOttrc9FDtUXgTLMHypMx0bV zNsV02DucRNWaFSpG6ZrXJMarqvC4NLihAFzhpo2QsGQSpTgiME= =suwp -END PGP SIGNATURE- -- 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/174d9e11-0e0a-7924-b8f8-5339b138358f%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Port Forward in qubes-OS.
Hello friends! Pls, help me :( I need to configure port forwarding to Kali linux VM via sys-net ---> sys-firewall ---> sys-whonix ---> VPN-VM ---> KaliVM to use meterpreter and apache2 on my Kali linux VM. At first I tried to use scripts: https://gist.github.com/jpouellet/d8cd0eb8589a5b9bf0c53a28fc530369 https://gist.github.com/Joeviocoe/6c4dc0c283f6d6c5b1a3f5af8793292b https://github.com/niccokunzmann/qvm-expose-port I transferred them to the dom0 machine in the / usr / local / bin / folder I tried to run these scripts, but ports 443, 8080, 80 do not work on Kali linux VM. Then i tried to do it manually https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world [user@sys-net ~]$ ifconfig | grep -i cast ens6: flags=4099 mtu 1500 ens5f0u1: flags=4163 mtu 1500 inet 192.168.0.157 netmask 255.255.255.0 broadcast 192.168.0.255 vif3.0: flags=4163 mtu 1500 inet 10.137.0.5 netmask 255.255.255.255 broadcast 0.0.0.0 wls7: flags=4099 mtu 1500 [user@sys-net ~]$ ifconfig | grep -i cast ens6: flags=4099 mtu 1500 ens5f0u1: flags=4163 mtu 1500 inet 192.168.0.157 netmask 255.255.255.0 broadcast 192.168.0.255 vif3.0: flags=4163 mtu 1500 inet 10.137.0.5 netmask 255.255.255.255 broadcast 0.0.0.0 wls7: flags=4099 mtu 1500 [user@sys-net ~]$ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.0.157 -j DNAT --to-destination 10.137.0.6 [user@sys-net ~]$ sudo iptables -I FORWARD 2 -i eth0 -d 10.137.1.6 -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT [user@sys-net ~]$ sudo nft add rule ip qubes-firewall forward meta iifname eth0 ip daddr 10.137.0.6 tcp dport 443 ct state new counter accept [user@sys-net ~]$ sudo iptables -t nat -L -v -n Chain PREROUTING (policy ACCEPT 3 packets, 156 bytes) pkts bytes target prot opt in out source destination 15233 807K PR-QBS all -- * * 0.0.0.0/00.0.0.0/0 15220 806K PR-QBS-SERVICES all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DNAT tcp -- eth0 * 0.0.0.0/0 192.168.0.157tcp dpt:443 to:10.137.0.6 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 1546 packets, 104K bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * vif+0.0.0.0/00.0.0.0/0 3 156 ACCEPT all -- * lo 0.0.0.0/00.0.0.0/0 30894 2067K MASQUERADE all -- * * 0.0.0.0/00.0.0.0/0 Chain PR-QBS (1 references) pkts bytes target prot opt in out source destination 0 0 DNAT udp -- * * 0.0.0.0/010.139.1.1 udp dpt:53 to:10.139.1.1 0 0 DNAT tcp -- * * 0.0.0.0/010.139.1.1 tcp dpt:53 to:10.139.1.1 0 0 DNAT udp -- * * 0.0.0.0/010.139.1.2 udp dpt:53 to:10.139.1.2 0 0 DNAT tcp -- * * 0.0.0.0/010.139.1.2 tcp dpt:53 to:10.139.1.2 Chain PR-QBS-SERVICES (1 references) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- vif+ * 0.0.0.0/0 10.137.255.254 tcp dpt:8082 [user@sys-net ~]$ sudo iptables -L -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- vif+ * 0.0.0.0/00.0.0.0/0 tcp dpt:8082 0 0 DROP udp -- vif+ * 0.0.0.0/00.0.0.0/0 udp dpt:68 44760 4252K ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 ACCEPT icmp -- vif+ * 0.0.0.0/00.0.0.0/0 3 156 ACCEPT all -- lo * 0.0.0.0/00.0.0.0/0 0 0 REJECT all -- vif+ * 0.0.0.0/00.0.0.0/0 reject-with icmp-host-prohibited 62 2480 DROP all -- * * 0.0.0.0/00.0.0.0/0 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 660K 438M ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0
[qubes-users] Re: Broadcom brcm 4356 Wifi card not working
regarding the HVM approach, I have noticed that the whole device is missing, although I have added it to the VM: user@debian:~$ sudo lspci -k 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) Subsystem: Red Hat, Inc Qemu virtual machine 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] Subsystem: Red Hat, Inc Qemu virtual machine 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] Subsystem: XenSource, Inc. 82371SB PIIX3 IDE [Natoma/Triton II] Kernel driver in use: ata_piix Kernel modules: ata_piix, ata_generic 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) Subsystem: Red Hat, Inc QEMU Virtual Machine Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01) Subsystem: Red Hat, Inc Qemu virtual machine Kernel modules: i2c_piix4 00:02.0 VGA compatible controller: Device 1234: Subsystem: XenSource, Inc. Device 0001 Kernel modules: bochs_drm 00:03.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01) Subsystem: XenSource, Inc. Xen Platform Device Kernel driver in use: xen-platform-pci 00:04.0 Ethernet controller: Intel Corporation Ethernet Connection I219-LM (rev 21) Subsystem: Lenovo Ethernet Connection I219-LM Kernel driver in use: e1000e Kernel modules: e1000e -- 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/8370ba03-aa9f-4a7f-995b-c5574c41e4b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Broadcom brcm 4356 Wifi card not working
Hi, I have got a Lenovo L460 with Broadcom brcm4356 Wifi Adapter that I don't get working on Qubes. To isolate the problem, I have first installed a debian-9 directly on the machine and got this after some problems working (https://www.linuxquestions.org/questions/linux-wireless-networking-41/debian-broadcom-bcm4356-802-11ac-wireless-not-working-4175644801/) Steps to reproduce: - Have Qubes 3.2.1 (also tried Qubes 4.0.1-rc2 without success) - Create NetVM debian-9 based with device: -- 00:1f.6 Ethernet controller: Intel Corporation l219-LM (rev21) -- 03:00.0 Network controller: Broadcom Limited BCM4356 802.11ac Wireless Network Adapter (rev02) (cable based Ethernet works on qube without flaws) - install firmware-brcm80211_20180825+dfsg-1_all.deb and add brcmfmac4356-pcie.txt - Unload kernel module sudo modprobe -f brcmfmac - Load kernel module sudo modprobe brcmfmac - sudo dmesg | less [3.476763] usbcore: registered new interface driver brcmfmac [3.532479] e1000e :00:00.6 eth0: (PCI Express:2.5GT/s:Width x1) c8:5b:76:5c:5a:06 [3.532497] e1000e :00:00.6 eth0: Intel(R) PRO/1000 Network Connection [3.532587] e1000e :00:00.6 eth0: MAC: 12, PHY: 12, PBA No: FF-0FF [3.535156] brcmfmac :00:01.0: Xen PCI mapped GSI18 to IRQ28 [3.537736] brcmfmac: brcmf_chip_recognition: SB chip is not supported [3.537749] brcmfmac: brcmf_pcie_probe: failed 14e4:43ec [3.539846] e1000e :00:00.6 enp0s0f6: renamed from eth0 - user@debian-net:/lib64$ sudo lspci -k 00:00.6 Ethernet controller: Intel Corporation Ethernet Connection I219-LM (rev 21) Subsystem: Lenovo Ethernet Connection I219-LM Kernel driver in use: e1000e Kernel modules: e1000e 00:01.0 Network controller: Broadcom Limited BCM4356 802.11ac Wireless Network Adapter (rev 02) Subsystem: Lenovo BCM4356 802.11ac Wireless Network Adapter Kernel modules: brcmfmac user@debian-net:/lib64$ sudo ifconfig enp0s0f6: flags=4163 mtu 1500 inet 192.168.45.172 netmask 255.255.255.0 broadcast 192.168.45.255 inet6 fe80::eacd:816d:b465:e28a prefixlen 64 scopeid 0x20 ether c8:5b:76:5c:5a:06 txqueuelen 1000 (Ethernet) RX packets 29359 bytes 35630763 (33.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 17109 bytes 1910984 (1.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 26 memory 0xe160-e162 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 8 bytes 380 (380.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 8 bytes 380 (380.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 => if I install on the same machine debian-9 directly the wifi works => if I use qubes debian-9 NetVM I get "SB chip is not supported" even though device is attached to VM => Has anyone an idea/suggestion what I could do to get rid of the "SB chip is not supported"? I assumed I had the wrong firmware, but why can I use the exact same *deb package on the same machine successfully if I install debian directly on the same machine without qubes? P.S.: I have also tried to create a HVM with debian-9 installer: - if I install debian on the HVM the X Window gets messed up => black screen => need to switch on/off the machine - if I use live DVD on HVM => I can install package until reboot, run the modprobe brcmfmac command without error in dmesg, but the Wifi Adapter is not shown in the Network Manager Thanks for any help! -- 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/fa5c257b-f282-4291-ac3e-6197d51a45ea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Fed-28 update error
onsdag den 19. december 2018 kl. 05.34.37 UTC-5 skrev qube...@tutanota.com: > Hi, I updated the dom0 and after I tried to update the Fed-28 template. I get > following error: > > [user@fedora-28 ~]$ sudo dnf update > Last metadata expiration check: 0:27:37 ago on Wed 19 Dec 2018 11:04:23 AM > CET. > Dependencies resolved. > > Problem 1: cannot install the best update candidate for package > hplip-3.18.6-10.fc28.x86_64 > - nothing provides libnetsnmp.so.35()(64bit) needed by > hplip-3.18.6-11.fc28.x86_64 > Problem 2: cannot install the best update candidate for package > hplip-libs-3.18.6-10.fc28.x86_64 > - nothing provides libnetsnmp.so.35()(64bit) needed by > hplip-libs-3.18.6-11.fc28.x86_64 > Problem 3: cannot install the best update candidate for package > libsane-hpaio-3.18.6-10.fc28.x86_64 > - nothing provides libnetsnmp.so.35()(64bit) needed by > libsane-hpaio-3.18.6-11.fc28.x86_64 > Problem 4: package hplip-libs-3.18.6-10.fc28.x86_64 requires > hplip-common(x86-64) = 3.18.6-10.fc28, but none of the providers can be > installed > - cannot install both hplip-common-3.18.6-11.fc28.x86_64 and > hplip-common-3.18.6-10.fc28.x86_64 > - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64 > - cannot install the best update candidate for package > hplip-common-3.18.6-10.fc28.x86_64 > - nothing provides libnetsnmp.so.35()(64bit) needed by > hplip-libs-3.18.6-11.fc28.x86_64 > > Package Arch Version Repository Size > > Skipping packages with conflicts: > (add '--best --allowerasing' to command line to force their upgrade): > hplip-common x86_64 3.18.6-11.fc28 updates 110 k > Skipping packages with broken dependencies: > hplip x86_64 3.18.6-11.fc28 updates 16 M > hplip-libs x86_64 3.18.6-11.fc28 updates 204 k > libsane-hpaio x86_64 3.18.6-11.fc28 updates 127 k > > Transaction Summary > > Skip 4 Packages > > Nothing to do. > Complete! > > *** > > When doing the --best --allowerasing I get this: > > [user@fedora-28 ~]$ sudo dnf --best --allowerasing update > Last metadata expiration check: 0:28:55 ago on Wed 19 Dec 2018 11:04:23 AM > CET. > Error: > Problem 1: cannot install the best update candidate for package > libsane-hpaio-3.18.6-10.fc28.x86_64 > - problem with installed package libsane-hpaio-3.18.6-10.fc28.x86_64 > - nothing provides libnetsnmp.so.35()(64bit) needed by > libsane-hpaio-3.18.6-11.fc28.x86_64 > Problem 2: cannot install the best update candidate for package > hplip-libs-3.18.6-10.fc28.x86_64 > - problem with installed package hplip-libs-3.18.6-10.fc28.x86_64 > - nothing provides libnetsnmp.so.35()(64bit) needed by > hplip-libs-3.18.6-11.fc28.x86_64 > Problem 3: cannot install the best update candidate for package > hplip-3.18.6-10.fc28.x86_64 > - problem with installed package hplip-3.18.6-10.fc28.x86_64 > - nothing provides libnetsnmp.so.35()(64bit) needed by > hplip-3.18.6-11.fc28.x86_64 > > * > > Any help appreciated. > Thank you! I could not resolve the issue with the answers in this thread, but fedora mailinglist did help me resolve the issue. The solution provided is provided here: https://www.spinics.net/linux/fedora/fedora-users/msg488308.html The command resolving the issue is: sudo dnf --best --allowerasing --enablerepo=updates-testing update hplip Sincerely Max -- 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/8fe25630-8b8f-4ff8-974b-9e6ffdf5912e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Port Forward in qubes-OS.
Packets are not transmitted after I added port 80 and 8080 to sys-net. [user@sys-net ~]$ sudo iptables -t nat -L -v -n Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 15234 807K PR-QBS all -- * * 0.0.0.0/00.0.0.0/0 15221 806K PR-QBS-SERVICES all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DNAT tcp -- eth0 * 0.0.0.0/0 192.168.0.157tcp dpt:443 to:10.137.0.6 0 0 DNAT tcp -- eth0 * 0.0.0.0/0 192.168.0.157tcp dpt:80 to:10.137.0.6 0 0 DNAT tcp -- eth0 * 0.0.0.0/0 192.168.0.157tcp dpt:8080 to:10.137.0.6 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 70 packets, 4690 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * vif+0.0.0.0/00.0.0.0/0 3 156 ACCEPT all -- * lo 0.0.0.0/00.0.0.0/0 32702 2189K MASQUERADE all -- * * 0.0.0.0/00.0.0.0/0 Chain PR-QBS (1 references) pkts bytes target prot opt in out source destination 0 0 DNAT udp -- * * 0.0.0.0/010.139.1.1 udp dpt:53 to:10.139.1.1 0 0 DNAT tcp -- * * 0.0.0.0/010.139.1.1 tcp dpt:53 to:10.139.1.1 0 0 DNAT udp -- * * 0.0.0.0/010.139.1.2 udp dpt:53 to:10.139.1.2 0 0 DNAT tcp -- * * 0.0.0.0/010.139.1.2 tcp dpt:53 to:10.139.1.2 Chain PR-QBS-SERVICES (1 references) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- vif+ * 0.0.0.0/0 10.137.255.254 tcp dpt:8082 -- 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/b836b2de-d402-45a0-92a7-3e77f8b0cdbe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How risky is GPU pass-through?
On Monday, December 24, 2018 at 1:52:53 PM UTC+1, Hugo Costa wrote: > On Sunday, 23 December 2018 20:34:48 UTC, Demi M. Obenour wrote: > > Someone I know is interested in using QubesOS. However, they are also a > > gamer: if they could not have a Windows VM with access to a dedicated > > graphics card for use by games, then QubesOS is not an option for them. > > > > How risky is GPU pass-through? My understanding is that on most > > laptops, the primary (internal) display is connected to the integrated > > GPU. Therefore, it appears to me that the risks are no more than > > pass-through of the USB, Ethernet, or wireless controllers, all of which > > QubesOS does by default. > > Best option would be to dual boot. Unless that person is always switching > from game to desktop, this solution could probably be an acceptable > compromise. In my opinion, dual booting is just as risky as GPU pass-through, maybe more so. Having a GPU sandboxed in a VM that will never see production VMs would be ideal. Although if you only have one GPU then there is no better option at the moment. -- 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/ec711eb1-db78-417b-bf95-2e280cd474ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Port Forward in qubes-OS.
I need to forward the port to Kali Vm in order to use meterpreter and apache2 on my KaliVM: sys-net ---> sys-firewall ---> sys-whonix ---> VPN ---> KaliVM. This can be done? -- 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/0d427742-0590-46ee-bbe0-135ee96029a4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Port Forward in qubes-OS.
What mistake do I make? - [user@sys-net ~]$ ifconfig | grep -i cast ens6: flags=4099 mtu 1500 ens5f0u1: flags=4163 mtu 1500 inet 192.168.0.157 netmask 255.255.255.0 broadcast 192.168.0.255 vif3.0: flags=4163 mtu 1500 inet 10.137.0.5 netmask 255.255.255.255 broadcast 0.0.0.0 wls7: flags=4099 mtu 1500 [user@sys-net ~]$ ifconfig | grep -i cast ens6: flags=4099 mtu 1500 ens5f0u1: flags=4163 mtu 1500 inet 192.168.0.157 netmask 255.255.255.0 broadcast 192.168.0.255 vif3.0: flags=4163 mtu 1500 inet 10.137.0.5 netmask 255.255.255.255 broadcast 0.0.0.0 wls7: flags=4099 mtu 1500 [user@sys-net ~]$ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.0.157 -j DNAT --to-destination 10.137.0.6 [user@sys-net ~]$ sudo iptables -I FORWARD 2 -i eth0 -d 10.137.1.6 -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT ^ [user@sys-net ~]$ sudo nft add rule ip qubes-firewall forward meta iifname eth0 ip daddr 10.137.0.6 tcp dport 443 ct state new counter accept [user@sys-net ~]$ sudo iptables -t nat -L -v -n Chain PREROUTING (policy ACCEPT 3 packets, 156 bytes) pkts bytes target prot opt in out source destination 15233 807K PR-QBS all -- * * 0.0.0.0/00.0.0.0/0 15220 806K PR-QBS-SERVICES all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DNAT tcp -- eth0 * 0.0.0.0/0 192.168.0.157tcp dpt:443 to:10.137.0.6 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 1546 packets, 104K bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * vif+0.0.0.0/00.0.0.0/0 3 156 ACCEPT all -- * lo 0.0.0.0/00.0.0.0/0 30894 2067K MASQUERADE all -- * * 0.0.0.0/00.0.0.0/0 Chain PR-QBS (1 references) pkts bytes target prot opt in out source destination 0 0 DNAT udp -- * * 0.0.0.0/010.139.1.1 udp dpt:53 to:10.139.1.1 0 0 DNAT tcp -- * * 0.0.0.0/010.139.1.1 tcp dpt:53 to:10.139.1.1 0 0 DNAT udp -- * * 0.0.0.0/010.139.1.2 udp dpt:53 to:10.139.1.2 0 0 DNAT tcp -- * * 0.0.0.0/010.139.1.2 tcp dpt:53 to:10.139.1.2 Chain PR-QBS-SERVICES (1 references) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- vif+ * 0.0.0.0/0 10.137.255.254 tcp dpt:8082 [user@sys-net ~]$ sudo iptables -L -v -n Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- vif+ * 0.0.0.0/00.0.0.0/0 tcp dpt:8082 0 0 DROP udp -- vif+ * 0.0.0.0/00.0.0.0/0 udp dpt:68 44760 4252K ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 ACCEPT icmp -- vif+ * 0.0.0.0/00.0.0.0/0 3 156 ACCEPT all -- lo * 0.0.0.0/00.0.0.0/0 0 0 REJECT all -- vif+ * 0.0.0.0/00.0.0.0/0 reject-with icmp-host-prohibited 62 2480 DROP all -- * * 0.0.0.0/00.0.0.0/0 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 660K 438M ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/010.137.1.6 tcp dpt:443 ctstate NEW 163 8531 QBS-FORWARD all -- * * 0.0.0.0/00.0.0.0/0 0 0 DROP all -- vif+ vif+0.0.0.0/00.0.0.0/0 163 8531 ACCEPT all -- vif+ * 0.0.0.0/00.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 Chain OUTPUT (policy ACCEPT 3220 packets, 216K bytes) pkts bytes target prot opt in out source destination Chain QBS-FORWARD (1 references) pkts bytes target prot opt in out source destination [user@sys-net ~]$ sudo nft list table ip
Re: [qubes-users] Port Forward in qubes-OS.
On 20181225 at 00:25 -0800 menoldst...@gmail.com wrote: > Permission denied (you must be root) Sometimes a closer look at the error mesage solves the riddle. 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/4e1bb1c4675aa2a607af4e23d27dc01f4b720f92.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - R4.0 - AS Rock Z370 Extreme4, i7-8700k
Thanks for the brilliant work with qubes, I took value from the hardware support page to wanted to send in my data aswell. Can confirm everything works pretty much out of the box. Only issue I have is the Corsair k70 keyboard does need to be unplugged then plugged back in at boot when entering the password to decrypt, other than that works fine. Motherboard: ASRock Z370 Extreme4 CPU: Intel i7-8700k RAM: Corsair Vengance Please see attached HCL log Thanks Tristão Burkhart -- 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/02d1737a8e6952f24e7d6fee3474d021%40cock.li. For more options, visit https://groups.google.com/d/optout. --- layout: 'hcl' type: 'desktop' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: 'unknown' remap: 'yes' brand: | ASRock model: | Z370 Extreme4 bios: | P3.10 cpu: | Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz cpu-short: | FIXME chipset: | Intel Corporation Device [8086:3ec2] (rev 07) chipset-short: | FIXME gpu: | Advanced Micro Devices, Inc. [AMD/ATI] Malta [Radeon HD 7990/8990 OEM] [1002:679b] (prog-if 00 [VGA controller]) Advanced Micro Devices, Inc. [AMD/ATI] Malta [Radeon HD 7990/8990 OEM] [1002:679b] gpu-short: | FIXME network: | Intel Corporation Ethernet Connection (2) I219-V memory: | 32701 scsi: | TOSHIBA DT01ACA2 Rev: ABB0 CDDVDW SH-224DB Rev: SB01 Samsung SSD 840 Rev: BB6Q usb: | 2 versions: - works: 'FIXME:yes|no|partial' qubes: | R4.0 xen: | 4.8.3 kernel: | 4.14.18-1 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK ---
[qubes-users] SINIT module RACM update: access denied (Anti-Evil-Maid)
I'm installing AEM for the first time in Qubes 4 and noticed that the readme(https://github.com/QubesOS/qubes-antievilmaid/blob/master/anti-evil-maid/README) has been significantly expanded since 3.2, specifically it mentions to make sure to get the latest RACM update at the SINIT module instructions: "Also, make sure you have the latest RACM update, if available (2nd & 3rd gen): https://software.intel.com/system/files/article/183305/intel-txt-sinit-acm-revocation-tools-guide-rev1-0_2.pdf It's possible to use 3rd gen SINIT/RACM on 2nd gen platforms. In fact, the only RACM available at the time of writing is for the 3rd gen, while the 2nd gen platforms were also affected by the buffer overflow bug in old SINIT version." That is not a public link however, you need to login with an account. I have successfully registered an account and logged in, but then I get an Access Denied message when opening the link. -- 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/a8782179-ad68-4728-9da1-64229d71593d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Port Forward in qubes-OS.
вторник, 25 декабря 2018 г., 5:26:04 UTC+3 пользователь unman написал: > On Mon, Dec 24, 2018 at 06:08:27AM -0800, menoldst...@gmail.com wrote: > > Hello. Qubes-users. I installed Kali linux and now I need to make it so > > that apache2 would work not only on the local network, but also on the > > Internet. I need to do port forwarding ?? If so, can anyone tell me how to > > do this? > > > > Have you looked at the docs? > https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world Thank you. What needs to be done to upgrade? [user@sys-net ~]$ iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.0.151 -j DNAT --to-destination 10.137.0.4 iptables v1.6.1: can't initialize iptables table `nat': Permission denied (you must be root) Perhaps iptables or your kernel needs to be upgraded. -- 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/6d3adcc9-c04d-4077-83d9-510f4657fb2d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.