On Friday, August 1, 2014 at 2:08:31 PM UTC-4, hermankha...@gmail.com wrote: > Hello All, > > I've recently started having a problem (recent round > of Qubes patching and updates) with network connectivity in my Windows 7 > based VM's. I first noticed the issue in the AppVM and have checked the > Template VM and found this same problem. > > All my other Template VMs and AppVMs (Fedora 20) do not have this issue and > are working fine. > > The > problem is that the Windows 7 based VM's are unable to acquire an IP > address and relevant information therefore resulting in no network > connectivity. > > Not getting a response to DHCP requests, the AppVMs default to APIPA > addresses: > > Ethernet adapter Local Area Connection 2: > > > Connection-specific DNS Suffix . : > > Description . . . . . . . . . . . : Xen Net Device Driver > > Physical Address. . . . . . . . . : 00-16-3E-5E-6C-08 > > DHCP Enabled. . . . . . . . . . . : Yes > > Autoconfiguration Enabled . . . . : Yes > > Link-local IPv6 Address . . . . . : fe80::f104:4fd4:d67d:68c%14(Preferred) > > Autoconfiguration IPv4 Address. . : 169.254.6.140(Preferred) > > Subnet Mask . . . . . . . . . . . : 255.255.0.0 > > Default Gateway . . . . . . . . . : > > DHCPv6 IAID . . . . . . . . . . . : 318772798 > > DHCPv6 Client DUID. . . . . . . . : > 00-01-00-01-1B-2E-CE-A3-00-16-3E-5E-6C-06 > > > DNS Servers . . . . . . . . . . . : 10.137.2.1 > > NetBIOS over Tcpip. . . . . . . . : Enabled > > I > have tried to statically assign the IP address and subnet mask within > the VMs to what it should be (according to Qubes VM Manager), but I'm > unable to actually save the changes. Perhaps this is something that the > QubesTools within the AppVM are preventing me from doing? Not sure. > > The > following is the output of the firewall rules for this VM (Within > QubesManager it's a default deny, with ICMP and DNS allowed). My > thinking is that firewall rules may be irrelevant at this stage as the > Qubes DHCP server should be local to the segment? : > > [user@firewallvm ~]$ sudo iptables -L -nv --line-numbers | grep 10.137.2.10 > 11 0 0 ACCEPT udp -- * * 10.137.2.10 > 10.137.1.1 udp dpt:53 > 12 0 0 ACCEPT udp -- * * 10.137.2.10 > 10.137.1.254 udp dpt:53 > 13 0 0 ACCEPT tcp -- * * 10.137.2.10 > 10.137.1.1 tcp dpt:53 > 14 0 0 ACCEPT tcp -- * * 10.137.2.10 > 10.137.1.254 tcp dpt:53 > 15 0 0 ACCEPT icmp -- * * 10.137.2.10 > 0.0.0.0/0 > 16 0 0 DROP tcp -- * * 10.137.2.10 > 10.137.255.254 tcp dpt:8082 > 17 0 0 REJECT all -- * * 10.137.2.10 > 0.0.0.0/0 reject-with icmp-host-prohibited > > Also, > on FirewallVM, I can see that "vif3.0" has been created for this VM, > but there are no ARP entries in the ARP cache. "vif6.0" is an ARP cache > entry for another AppVM (Fedora 20) which is working fine. > > [user@firewallvm ~]$ arp -a > ? (10.137.1.1) at fe:ff:ff:ff:ff:ff [ether] on eth0 > ? (10.137.2.7) at 00:16:3e:5e:6c:05 [ether] on vif6.0 > > I > do remember a time a while back where I was having network connectivity > issues on my Windows AppVMs and I think it was due to an extra "vif" > being created on the firewallVM. Changing the firewallVM kernel to 11.3 > did fix things up back then. Through the course of regular updates, my > firewallVM kernel is currently 3.12.23-1. > > Thanks.
I was able to gain network access by changing the network adapter IPv4 address to the same IP address set for the DNS, class A subnet mask, and no gateway. I did receive a warning that this IP was in use. I have not however seen any issues arise. I have internet access on my windows vm with tools installed, as well as internet access on other vm's. -- 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/404ccef8-d3fa-4b24-bbb5-a479451eeef5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
