Network problems with Windows 7 HVM and AppVM

[hermankha...@gmail.com]

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.

[hermankha...@gmail.com]

I've also noticed that when turning the VM on, there's two entries created when running the "xl list" command on Dom0:

e.g.

workvm
workvm-dm

All the other AppVMs (working) only have a single entry.

Running a "sudo xl -v top" command also shows both the "workvm" and the "workvm-dm" running. If I try and kill the "workvm-dm" then the GUI of the workvm becomes unresponsive and I have to kill it also.

Another thing I've noticed is that the Windows Template HVM and the Windows AppVM both have the same MAC address as per the "qvm-prefs" command. Is this normal?

[Marek Marczykowski-Górecki]

On 01.08.2014 20:08, 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,

IP in Windows VMs isn't configured by DHCP, there should be dedicated service
for that installed as part of Qubes Tools.

> 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.

Check status of "Qubes Network Setup" (or sth like this) service. Try to
restart it.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Marek Marczykowski-Górecki]

On 02.08.2014 08:07, hermankha...@gmail.com wrote:
> I've also noticed that when turning the VM on, there's two entries created
> when running the "xl list" command on Dom0:
>
> e.g.
>
> workvm
> workvm-dm
>
> All the other AppVMs (working) only have a single entry.

This is totally normal for all HVMs.

> Running a "sudo xl -v top" command also shows both the "workvm" and the
> "workvm-dm" running. If I try and kill the "workvm-dm" then the GUI of the
> workvm becomes unresponsive and I have to kill it also.
>
> Another thing I've noticed is that the Windows Template HVM and the Windows
> AppVM both have the same MAC address as per the "qvm-prefs" command. Is
> this normal?

This is also normal - some VM settings are automatically inherited from VM
template. Duplicated MAC here shouldn't make any harm, as those VMs are not
connected to the same layer 2 network (switch/bridge).

[hermankha...@gmail.com]

On Saturday, August 2, 2014 9:26:37 PM UTC, Marek Marczykowski-Górecki wrote:

Check status of "Qubes Network Setup" (or sth like this) service. Try to
restart it.

 Thank you for the response Marek. The Qubes Network Setup service is not running and I'm unable to start it successfully (even after multiple reboots): I get the following information:

"Error 1: Incorrect function."

There's nothing more detailed in the Windows Event Logs either.

Screenshot is attached

[Rafał Wojdyła]

We've seen this error a few times but it's pretty intermittent and I
couldn't pinpoint the root cause yet. Upcoming Windows Tools version
will contain a few reliability improvements and a more robust logging
system that should help with cases like that when I can't easily
reproduce them on my test machines.
--
Rafał Wojdyła
Qubes Tools for Windows developer

[hermankha...@gmail.com]

I've looked into this issue a bit deeper and finally resolved it.

Along with doing a bunch of Qubes Updates, I also did Windows Updates and installed some new software into the Template VM. The OpenVPN client was one of the additional bits of software installed.

If I manually try to run "qubes-network-setup.exe" via the CLI:

c:\Program Files\Invisible Things Lab\Qubes OS Windows Tools\bin>qubes-network-s etup.exe
AddIPAddress failed with 5010

If I manually disable the OpenVPN Client Network Adapter (Control Panel >> Networking), then I have no problems with acquiring an IP address. Interestingly I've also got the Cisco AnyConnect VPN client software installed (but by default this is disabled).

So could it be a problem in the way the QubesWindowsTools handle additional network interfaces which are added or installed after the installation of the tools themselves?

I hope the above information has been helpful for you, I've got a workaround in place.

Let me know if you need more information from my side although I think it should be easily reproducable.

[mihaig...@gmail.com]

Thanks for posting,
I have the same problem since installing a CheckPoint Client Network Adapter and as you said, manually disabling it fixes the IP address immediately.

Tried to repair QWT installation (to see if repair/reinstall with the CheckPoint VPN already present fixes something) but the problem is still there.

[seektruthf...@gmail.com]

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.

[wordsw...@gmail.com]

> 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.

This worked for me as well, but it does bother me... I guess Windows thinks that it's taken that IP, but in reality is hasn't? It doesn't seem to affect anything outside of the Windows VM itself...