Re: [qubes-users] Celeron N3350 and VT-d
newpa...@gmail.com: On Monday, October 8, 2018 at 8:10:17 AM UTC-6, awokd wrote: Now, for the actual question. :) The installer reports missing IOMMU/VT-d/AMD-Vi, however the machine's motherboard is an Intel Celeron N3350 which, according to https://ark.intel.com/products/95598/Intel-Celeron-Processor-N3350-2M-Cache-up-to-2-4-GHz-, should have VT-d (unless it needs a specific kind of VT-d?). I am not sure about IOMMU, perhaps it is missing. Does the error message list those as alternatives of the same thing? Or is it that I may have VT-d but not IOMMU, and the error just lists them all if just one has not been detected? Did you enable the possibly multiple virtualization options in your UEFI config? There are actually no virtualization options in my UEFI config. I do get to turn off secure boot and some TSC stuff, but not much else. There's no vmx flag in /proc/cpuinfo (less that file after ctrl+f2 during installation), but apparently Qubes is not complaining about a lack of VT-x. There is a hypervisor flag, however. It's possible your CPU supports the features, but not your motherboard's chipset and/or UEFI. Not having any options in the config for it is generally a bad sign. Check to see if there's a firmware update available for your board. VT-d implies there's at least one IOMMU, and VT-x is present on everything with VT-d. -- 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/bd3c38d2-e1b7-eaef-5bf7-800a1308708c%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Celeron N3350 and VT-d
On Monday, October 8, 2018 at 8:10:17 AM UTC-6, awokd wrote: > > > > Now, for the actual question. :) The installer reports missing > > IOMMU/VT-d/AMD-Vi, however the machine's motherboard is an Intel Celeron > > N3350 which, according to > > https://ark.intel.com/products/95598/Intel-Celeron-Processor-N3350-2M-Cache-up-to-2-4-GHz-, > > should have VT-d (unless it needs a specific kind of VT-d?). I am not sure > > about IOMMU, perhaps it is missing. Does the error message list those as > > alternatives of the same thing? Or is it that I may have VT-d but not > > IOMMU, and the error just lists them all if just one has not been detected? > > Did you enable the possibly multiple virtualization options in your UEFI > config? There are actually no virtualization options in my UEFI config. I do get to turn off secure boot and some TSC stuff, but not much else. There's no vmx flag in /proc/cpuinfo (less that file after ctrl+f2 during installation), but apparently Qubes is not complaining about a lack of VT-x. There is a hypervisor flag, however. -- 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/4840c644-5351-45ba-8e0b-270ff1adad14%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Changing USB Controllers
Here are the usb controllers when I type in 'sudo lspci -v' 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USb xHCI (Rev 05) (prog-if 30 [XHCI]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec Flags: bus master, medium devsel, latency 0, IRQ 57 Memory at f7b0 (64-bit, non-prefetchable) [size=64k] Capabilities: [70] Power Management version 2 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USb EHCI #2 (Rev 05) (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec Flags: bus master, medium devsel, latency 0, IRQ 16 Memory at f7b18000 (32-bit, non-pcopy and pasterefetchable) [size=1k] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USb EHCI #1 (Rev 05) (prog-if 20 [EHCIReciever]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at f7b17000 (32-bit, non-prefetchable) [size=1k] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features Kernel driver in use: ehci-pci Kernel modules: ehci_pci when I type in 'sudo lsusb -v' Here are the buses. Bus 002 Device 002: ID 8087:8000 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub iProduct 2 EHCI Host Controller iSerial 1 :00:1d.0 Bus 001 Device 002: ID 8087:8008 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub iproduct 2 EHCI Host Controller iSerial 1 :00:1a.0 Bus 004 Device 002: ID 04e8:61f5 Samsung Electronics Co., Ltd Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub iProduct 2 xHCI Host Controller iSerial 1 :00:14.0 Bus 003 Device 007: ID 1770:ff00 Bus 003 Device 005: ID 8087:07dc Intel Corp. Bus 003 Device 004: ID 045e:00e1 Microsoft Corp. Wireless Laser Mouse 6000 receiver Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub iProduct 2 xHCI Host Controller iSerial 1 :00:14.0 -- 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/cc49162d-7fc8-4064-8b25-edece724e1e9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Is it possible to install Qubes OS on another Internal Hard Drive partition?
If so, how do you do 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/3f51bf4d-3a0a-4164-bf44-48bd3bd918e9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Mouse driver xorg (evdev)
I'm using multiple usb mouses/trackballs which need an section with the options for the evdev driver specified to make them function properly. Where to put these .conf files? I can only think of /etc/X11/xorg.conf.d in either dom0 or the template on which the sys-usb VM is based. Or is this all wrong? I searched the docs and mailing list for the Qubes way to do this, but couldn't find an answer. Best, Marc -- 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/alpine.DEB.2.20.1810082104380.1261%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installing qr-exec on HVM
Update: Got all services to run, including qubes-gui-agent. Turns out the dependency it was failing on was meminfo-writer which was enabled in the /usr/lib/qubes/init/qubes-sysinit.sh script, but promptly disabled because it wasn't "checkmarked" in dom0's VM settings page. That said, with all services running, still same behavior of getting no replies to "qvm-run --pass-io" nor does any qvm-run for executing commands, e.g., touch. qubes-db.service qubes-early-vm-config.service qubes-meminfo-writer.service qubes-mount-dirs.service qubes-qrexec-agent.service qubes-sysinit.service -- 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/5027edf3-e726-47c5-b75e-b6e95428baa7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Open in Qube 3.0.1 beta released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Qubes community, I've released a new version of "Open in Qube" (aka qubes-url-redirector) [v3.0.1_beta] because I fixed a bug in a function (makeUrl) that simplify the build process of a whitelisted entry. The announce about the previous release is at [v3.0_beta post]. ### Upgrade The upgrade process is the same of installation (on the updated repo). ## Firefox On Firefox every entry is preserved. Furthermore each entry affected by this bug will be converted to the correct one. So no user interaction is needed. ## Chrome/ium Unfortunately on Chrome/ium you need to repopulate the whitelist (due to the packaging process, I also fixed this behavior for future release). [v3.0_beta post] = https://groups.google.com/forum/#!topic/qubes-users/gcKkbJ8EaXA [v3.0.1_beta] = https://github.com/raffaeleflorio/qubes-url-redirector/releases/tag/v3.0.1_beta Best Regards, Raffaele. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEXw2ov1HEFPFo+AVy07vJZYtrAOMFAlu7klUACgkQ07vJZYtr AOPGXA//YekM5JcC00OGHFhdxyLzt3fgrclEXv3t8xlFlZAaSMjdBaNrdmWmNTnr yKgBBQqIFlORlz9TMnzuIWZqoKcVeFabVxTTqFGvXIYWGLRy4UKA/dnnjQQP6fzI npON7gD6+Jwt/DzyoVlRmmU99TAQ7Ow26rxrZuh5/8AaDNtCzIJSQeLejHima0ri Z745t1kpkCtb9GTIyHBvrGrFPwL5hZs9gypLAE3XJe4gWr1L9m58XlUtF+7xut0v hmx+YdH77Y5XBksAF3NKZYl9a1BW34VjqNnecucgljTu9kfeeqaQH7Xzixrkkc8W VslRBTidKYK6UodhrbgPxXDSmCU4LgPbz7Wp4NTLXOgZs6xtVjSOcTpC1TRFHH5x fJOpZ6/dMyJpw3VxyIXQGKfE+kKx+2//DMG22gEKydmXqtQVmbXeMUOfeHKJ7sZz PqpwAbjBJB5JWr+XBZQopR8nBQfMKgpVq1H3GmywQ7bbPtw8rnPKIaEUNotZ2UhO QlFEF+djF9nViY7MUOMM0mJy1j5Y4CbDFThEIA/jJOQpwjm7RlUn3T+xxMlRqLlD NyJhclxdHsr1wpgNthrTFaCjHrKD0okkyH1qP2dB4d9gdv8cUNltrm62NDx0/nKZ OGocfydEngupWLCA2xnXE1q814ec44x3YddcomiE3lypuSkYS1A= =HvpF -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/S7pDYIFm2JQ_ocVzcRUnjxDd47zgW5959IsveNZKPf-9G4UPDjzeW6lCujEq7Reqij49wOUnxh5ElB22rU7H85jM38mMhRlJT3trUbiIqyE%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] nftables vs iptables
On 10/2/18 2:25 AM, Ivan Mitev wrote: On 10/2/18 1:32 AM, Chris Laprise wrote: On 10/01/2018 05:48 PM, mfreemon wrote: On 1/11/18 3:01 PM, Chris Laprise wrote: > On 01/10/2018 03:47 PM, Connor Page wrote: >> The official templates use nftables so shouldn’t be mixed with iptables. I didn’t have time to learn about nftables, so just removed nftables package from debian 9 template. YMMV. > > Hmmm, I was just thinking how Qubes' own guest scripts still use > iptables even in fedora-26. > > IIUC, iptables and nft are two different interfaces to netfilter. I > don't know if it really matters, at least for the R4.0 window. I'd > prefer to put the syntax change (for docs) off until a later release. I was recently thrown by the mix of both nftables and iptables in R4. The qubes docs don't clarify much. The qubes firewall scripts use nft. Most of the discussion on the qubes website documentation is about iptables, but there are also a few mentions of nft. The upgrade instructions (going from R3.2 to R4) did not mention converting rules from iptables to nftables. It looks like other related projects (one example is qubes-tunnel) is using iptables. Just reading a few things and trying to come up to speed, I get the impression that nftables and iptables should not both by used at the same time. Even if technically possible (i.e. both sets of rules applied correctly), it strikes me as not a great idea to maintain packet filtering rules in two different ways. What is the best practice recommendation on this (for R4, Fedora 28 template)? Are we to be using, exclusively, nftables in R4? The last I read about this (for 4.0) is that nftables is used in Fedora Qubes code, but Debian Qubes is still using iptables. That still appears to be the case since nftables is not installed in my debian-9 templates. I've submitted qubes-tunnel to Qubes with iptables commands only, with the intention to transition to nftables (or that other new interface in Linux, name escapes me just now) for Qubes 4.1. Someone who is just starting a project might be better off going with nftables. ... until yet another packet filtering mechanism replaces nftables (in that case, bpfilter [1]). I understand the rationale behind using nftables [2] but given how it is widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it wasn't worth it. The OP's post confirms there's quite some confusion about how it interacts with iptables, and the official documentation is far from helpful. I'm quite proficient with iptables and networking in general but it took me half an hour to understand how to tweak Qubes' nftables rules last time I wanted to change something in the firewall, while I would have done that task in less than one minute with iptables. I could have spent a few hours learning nftables to improve the official doc but at my age I prefer to spend time learning tech that significantly improves things (eg. Qubes OS over standard linux distribution) over loosing time learning stuff that is only marginally better. Anyway - I digress :) [1] https://old.lwn.net/Articles/747551/ [2] https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500 I'm concerned about the confusion and unnecessary complexity here. Network packet filtering is certainly (one of) those features that software such Qubes needs to be solid on (in both design approach and implementation detail). Is the Qubes team confident in the current situation, such that users of Qubes should not be concerned? nb. This is not meant to be a criticism at all. I very much appreciate the hard (and complicated) work going into Qubes. I'm just looking to understand the current situation better so as to judge whether my concern is warranted or not. -- 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/730fa03d-d105-ab76-6297-21039ebb584a%40zoho.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Ubuntu templates
It's now straight forward to build templates for bionic as well as xenial, using qubes-builder. If you want to try them out before building, I've uploaded freshly built templates for 4.0, including a fairly hefty xenial-desktop template. You can find details at https://qubes.3isec.org Updated packages are available from the repositories there, if you already have a working template. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To 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/20181008142823.si4a2aw7i5fhifch%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Celeron N3350 and VT-d
newpa...@gmail.com wrote on 10/8/18 5:42 AM: Now, for the actual question. :) The installer reports missing IOMMU/VT-d/AMD-Vi, however the machine's motherboard is an Intel Celeron N3350 which, according to https://ark.intel.com/products/95598/Intel-Celeron-Processor-N3350-2M-Cache-up-to-2-4-GHz-, should have VT-d (unless it needs a specific kind of VT-d?). I am not sure about IOMMU, perhaps it is missing. Does the error message list those as alternatives of the same thing? Or is it that I may have VT-d but not IOMMU, and the error just lists them all if just one has not been detected? Did you enable the possibly multiple virtualization options in your UEFI config? -- 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/c57dbe5d-74d3-fa00-6a0b-73df45e68ce0%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] XL VM connectivity to Qubes Network
On Mon, Oct 08, 2018 at 03:27:43AM -0700, 3mp...@gmail.com wrote: > On Tuesday, September 25, 2018 at 9:24:08 PM UTC+2, 3mp...@gmail.com wrote: > > > Some obvious questions. > > > > > > You say the interface is correctly configured. > > > Do you have any routes set in the Windows box? > > > Do you see traffic outbound on the 10.137.0.50 iface? > > > > > > If you sniff traffic inbound on the vif attached to the Windows HVM, do > > > you see anything there? (I mean sniff on the proxyVM) > > > > Hi Unman, thanks for your help. > > > > To eliminate some potential Windows issues I chose to boot on a fedora 28 > > live cd in this HVM. > > > > I configured the eth0 interface with the following command to copy a normal > > qubes configuration : > > > > ifconfig eth0 10.137.0.200 (HVM IP) netmask 255.255.255.255 broadcast > > 10.255.255.255 > > route add -host 10.137.0.10 (ProxyVM IP) dev eth0 > > route add default gw 10.137.0.10 eth0 > > > > I identified vif14 on ProxyVM, it corresponds to the HVM interace. > > > > I launched tcpdump -n -i vif14.0 on ProxyVM, telnet from 10.137.0.200 (HVM) > > to 10.137.0.8 port 8080 (web server on qube I'm trying to reach, working > > great from a third qube) > > > > telnet doesn't connect but here's the result of tcpdump : > > > > https://pastebin.com/QXhyBx4Z > > > > Any help appreciated > > Could someone help me on this issue ? Or explain the right network > configuration in Qubes 4.0 ? The 255.255.255.255 netmask seems strange to > me... Is the idea to block all kind of traffic except to the gateway with the > route add -host commmand ? > I believe that is indeed the aim. You can either set to 255.255.255.0 or add specific route, as you have done. (Did you set a return route on the destination also?) The next step would be to examine the rules on the proxy to make sure that you are allowing the traffic through the ProxyVM. You could listen on the interface that's attached to 10.137.0.8 to see if traffic is outbound from there. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To 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/20181008135548.g4wsss6ld25qfvg3%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Changing USB Controllers
On Sun, Oct 07, 2018 at 06:31:04PM -0700, alexw8...@gmail.com wrote: > Hello, I have qubes (r4.0) installed on a USB. I have 3 USB Controllers on > my laptop. When I am running qubes and try attaching a USB device, it > always uses the same USB Controller(the usb qubes is installed/dom0) > regardless of the USB port I am using. > > Is there a way to switch this? I wanted to try and create a USB qube just > for untrusted usb devices. I know I cant use the one dom0 is on but I have > two more controllers I would like to utilize if possible for this. > Are you sure you have 3 controllers? Many laptops only have one. It sounds as if you have 1 controller and 3 attached ports. You can't change this without hardware modification. Some laptops have controllers allocated to "internal" devices like mouse/keyboard, but not to external ports. Not much use to you. Check the output of 'sudo lsusb -v' and 'sudo lspci -v' unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To 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/20181008134111.zd6wv4wff6tzzqrc%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Android Studio AVD emulate
On Thursday, September 13, 2018 at 9:27:09 AM UTC-7, Andrzej Andrzej wrote: > Any idea? If you really want to do it on your own host, AVD manager / create virtual device / choose device / select system image / Other Images / click "download" on an android image and finish. but thats very slow and tends to be error prone. take advantage of our networked world, and run a vagrant server. host os linux, with vagrant-libvirt (which uses kvm) and make sure nested virtualization is enabled, which is why your not going to use virtualbox for this. then grab this script, https://gist.github.com/xahare/1db2970b7b684c0d54c0c15cc32afb98 and set a VAGRANTHOST in your .bashrc also, vagrant plugin install vagrant-sshfs you can install virt-manager in the fedora-28 templatevm, and set it to your vagranthost. you'll have to remove its connection to localhost (xen). in my case, i added src to .gitignore (so it doesnt get clobbered) and rsync that code as needed. rvagrant uses .gitignore, but you dont need a git repo there. you can make your git repos in your studio projects instead. if you do a vagrant halt and up, (like after software updates) run vagrant provision to fix the permissions of /dev/kvm (it will complain about snap installing an existing package. you can ignore that) the first time the emulator runs, it will be slow, but after that, its fast enough that all this trouble is worth it. heres my Vagrantfile. my vagrant host only has 2 cores, but i suggest 4 if you have the hardware. and yes, you really want 10 gigs of ram in it. android studio is a hog. # -*- mode: ruby -*- # vi: set ft=ruby : VAGRANTFILE_API_VERSION = "2" setup = <<-SCRIPT apt-get -y install vim-gtk3 git openjdk-8-jdk openjdk-8-jre snap install android-studio --classic chgrp vagrant /dev/kvm chmod g+rw /dev/kvm SCRIPT Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "peru/ubuntu-18.04-desktop-amd64" config.vm.synced_folder "src", "/home/vagrant/src", type: "sshfs" config.vm.provider "libvirt" do |lv| lv.nested = true lv.cpus = 2 lv.memory = 10240 end config.vm.provision "shell", inline: setup end -- 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/3d5dc716-8234-4526-930a-d8bbbcfc658e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] XL VM connectivity to Qubes Network
On Tuesday, September 25, 2018 at 9:24:08 PM UTC+2, 3mp...@gmail.com wrote: > > Some obvious questions. > > > > You say the interface is correctly configured. > > Do you have any routes set in the Windows box? > > Do you see traffic outbound on the 10.137.0.50 iface? > > > > If you sniff traffic inbound on the vif attached to the Windows HVM, do > > you see anything there? (I mean sniff on the proxyVM) > > Hi Unman, thanks for your help. > > To eliminate some potential Windows issues I chose to boot on a fedora 28 > live cd in this HVM. > > I configured the eth0 interface with the following command to copy a normal > qubes configuration : > > ifconfig eth0 10.137.0.200 (HVM IP) netmask 255.255.255.255 broadcast > 10.255.255.255 > route add -host 10.137.0.10 (ProxyVM IP) dev eth0 > route add default gw 10.137.0.10 eth0 > > I identified vif14 on ProxyVM, it corresponds to the HVM interace. > > I launched tcpdump -n -i vif14.0 on ProxyVM, telnet from 10.137.0.200 (HVM) > to 10.137.0.8 port 8080 (web server on qube I'm trying to reach, working > great from a third qube) > > telnet doesn't connect but here's the result of tcpdump : > > https://pastebin.com/QXhyBx4Z > > Any help appreciated Could someone help me on this issue ? Or explain the right network configuration in Qubes 4.0 ? The 255.255.255.255 netmask seems strange to me... Is the idea to block all kind of traffic except to the gateway with the route add -host commmand ? -- 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/9724addd-d087-4f64-ab60-32ce5b7a9437%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
