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.