Cannot log in to Microsoft Account over VPN

Abstract

I am using a VPN (proxy) to improve the access performance to global websites. There was a minor issue that I struggled with for a long time. I could not log in to any Microsoft account when using a VPN. The solution is to add the Your account to the loopback exemption. However, I’ll explain the reason in this post.

Explanation

Microsoft used a different way to run applications on Windows 8 and later versions. It is called AppContainers. This change leads to some applications not working with VPN (proxy) since it blocks some data exchanges between applications. The change is for security reasons. It basically isolates each application to block the communication on the local computer level.

But, Microsoft offers a way to exempt applications for troubleshooting purposes. Hence, adding the applications to the exemption work around the problem.

Following are some useful commands for exemption with Windows native commands:

# Show a list of loopback exemption
CheckNetIsolation.exe LoopbackExempt -s

# Add an application to the exemption
CheckNetIsolation.exe LoopbackExempt –a –n=<app name>

It’s not easy to figure out the application name or ID. You should use Process Explorer. However, you can also download the 3rd party tool “Windows 8 AppContainer Loopback Utility” to configure it.

AppContainer Loopback Exemption Utility — Utility interface

Reference

How to enable loopback and troubleshoot network isolation (Windows Runtime apps) – Windows app development | Microsoft Docs

AppContainers for Windows 8: What Are They and How Can You Create Them? | by Apriorit | Apriorit — Specialized Software Development Company | Medium

AppContainer Isolation – Win32 apps | Microsoft Docs

Allow an Application to bind and listen on a port to honor requests from outside the app (microsoft.com)

Disable DHCP Service for VMware Fusion in Big Sur

Article background. It's a LED screen with yellow text: "DHCP: No Services"

My home lab virtual machines are connected on private network 192.168.1.x. All internet traffic goes to a gateway server and is forwarded over the internet network adapter. The gateway server is a DHCP server also to assign IP addresses to my lab devices. The benefit to use my own DHCP server is I can control some advanced DHCP settings in the simple GUI interface. However, I didn’t find the DHCP settings on VMware Fusion 12 for the private network. And my VMs got 172.x.x.x DHCP IP addresses automatically.

The reason is I’m using macOS Big Sur. Apple requests developers to use the vmnet framework for network virtualization programming. The framework only offers limited functions for virtualized networking. This limitation is confirmed by VMware staff in the community.

Since macOS has its own DHCP server. One workaround is to disable the native DHCP server by following the command which is mentioned in the same post:

sudo /bin/launchctl unload -w /System/Library/LaunchDaemons/bootps.plist

Password is incorrect when access admin$ or c$ on Windows

There are default shares for administration purposes on Windows. You can access it by //computer name/admin$ or //computer name/c$.

You may see the “password is incorrect” error when accessing the network shares. Even you entered the correct password for the machine.

The problem is the Windows local group policy is using guest only mode for sharing. But the guest account is disabled on the target machine.

You need to run gpedit.msc to open Local Group Policy Editor. And change the option “Sharing and security model for local accounts” to Classic.

The network access option in Windows Local Group Policy

Quick Notes: Windows lost network every 20 minutes

You may see a Windows machine lost network connectivity every 20 minutes. Or you may see the Windows machine lost network when you are connecting it via remote desktop protocol (RDP). I wrote an article to discuss virtual machine lost network connectivity problem on Emulex powered ESXi host. You may want to check out if you are running legacy ESXi and HPE hardware.

You may see following error if you check Application event log:

Source: Dot3Svc
Event ID: 15506
Description: Network authentication attempts have been temporarily suspended on this network adapter.

Or following error:

Source: Dot3Svc
Event ID: 15514
Description: Wired 802.1X Authentication failed.

There is a Reason Code in the event logs above. The code could be 327685, 327682, or 327626.

The reason is the Windows machine cannot get authenticated on an authentication enabled network. It could be certification file expired on the machine or server side, or something wrong between its.

Actually you can workaround this issue by disable “Enable IEEE 802.1x authentication for this network” option in Authentication tab in the network adapter Properties.

Please refer to Microsoft official document “advanced troubleshooting 802 authentication” if you want go deeper.

Private IP Address Routes to L3 Subnet on Dual vNIC VM

It’s not easy for me to describe the issue in one line on the title. Let me give some background here. I have 2 set of VMs. Set 1 has VM A & VM B. Set 2 has VM C & VM D. Each VM has a vNIC configured with a private IP address. VM A and VM C also have another vNIC configured with an L3 (Routable) IP address. Each set’s private IP addresses are the same. To make sure no confusion I implemented a vRouter VM for each set. The vRouter is same as VM A or VM C, it has two vNICs. One is connected to L3 network, another is connected to the private network. This way can keep the private network traffic not going outside of the set. So the both set no disturb each other when I set same private IP addresses.

Following are IP addresses I set for each VM:

VM A: 192.168.0.11
VM B: 192.168.0.12
VM C: 192.168.0.11
VM D: 192.168.0.12

The problem is I still can get ping responding on VM A to 192.168.0.12 when I turn off VM B. I expected to see the L2 traffic goes to it own vRouter and finds VM B is offline. But tracert command shows me the traffic goes from VM A’s L3 network to vRouter of the 2nd set, and then get the answer from VM D. Looks like the L2 ping package is broadcasting on L3 network.

The issue was fixed by enabling a feature on L3 network. It called “Enforce Subnet Check for IP Learning“. Cisco changed the name to “Limit IP Learning To Subnet“. It’s a VLAN level setting. It will not allow broadcasting the private Ip traffic on an L3 network. It forces private IP traffic to go to L2 network only.

Emulex OneConnect OCe10102 on ESXi 6.0

Please refer to following post for basic troubleshooting of Emulex OneConnect.

How to Install Proper Drivers for 3rd Party Network Adapter on ESXi 5.x

I have a box uses Emulex OneConnect OCe10102 network adapters. The adapter is quite old and Emulex brand card doesn’t support ESXi 6.0. I upgraded the server to ESXi 6.0 and the Emulex adapters lost.

In the initial troubleshooting, I noticed that the adapters are still visible in BIOS. So it should be some driver level issues. I checked VMware Compatibility Guide. The model OCe10102 doesn’t support by ESXi 6.0.

If you run the following command you will still be able to see the adapters in PCI list on ESXi.

[code language="perl"]
esxcli hardware pci list
[/code]

So it indicates the adapters are not visible in ESXi since the newer Emulex driver doesn’t contain the model of the adapter in ESXi 6.0 native driver.

Then I uninstalled the native Emulex driver for ESXi 6.0 by the following command and rebooted the ESXi host.

[code language="perl"]
esxcli software vib remove -n elxnet
[/code]

The adapters still not visible after rebooting since no any drivers for Emulex adapters. Then I downloaded the Emulex drivers for ESXi 5.5 on VMware website and uploaded the “offline” package in the zip file to /tmp directory of the host. Then installed the driver by the following command:

[code language="perl"]
esxcli software vib install -d "/tmp/xxxxx.zip"
[/code]

The adapters appeared after rebooting the host.

Troubleshooting Network Performance of Virtual Machine

There are several layers of networking on the virtualization infrastructure. Guest operating system, Virtual Machine, ESXi driver, physical network adapters, RJ45/SFP and network switches…etc. Sometimes it’s hard to say where exactly caused a problem. Especially hardware layer problems. Today I worked on a very interesting case, it may give some ideas to troubleshooting network performance issue which is caused by hardware layers.

A user told me he was bothered by network performance of a virtual machine. It’s slow to copy data to NFS share. But responding to “ping” command looked good. I didn’t see any issue on virtual machine layer. VMware Tools was up to date, Windows OS was patched, virtual network adapter type was VMXNET3 and VM version was also up to date.

When I tried to copy an image file to share folder of the virtual machine, I did see sometimes speed was fast, but sometimes not. Since I have two physical uplinks, it led me to guess it could be one of the uplinks.

After a lot of swapping and cable changing, we eventually figured out there was a bad SFP on network switch end. I was able to observe the issue by using “psping.exe” of Microsoft Sysinternals. I used the following command to send the different size of ping package to the virtual machine. Network drops were increasing when I increased package size.

psping.exe -l <size of package> <Destination>
Example: psping.exe -l 4k xxxx.contoso.com

The size could be 1k, 2m or even larger. I think this is a good way to identify problem outside of ESXi. Especially SFP problem as such kind of problem didn’t give any CRC or error count on network switch level.

You can also use Windows native command “ping.exe” as following. The size unit is “bytes”. For example, you need to input 4096 if you want to send 4kb.

ping.exe -l <size> <Destination>
Example: ping.exe -l 4096 xxx.contoso.com

虚拟主机无法获得DHCP IP地址

刚解决了一个问题，快速更新一下。当虚拟主机无法获得DHCP IP地址时，应该做的第一件事情是检查防火墙，无论是Windows防火墙或者物理防火墙。UDP端口67和68不能被阻挡掉。否则会出现虚拟主机只能获得169.x.x.x的IP地址，这个地址是不可用的，表示虚拟主机无法从DHCP服务器获得地址。

这两个端口是DHCP客户端用来从DHCP服务器获取IP地址的。具体的技术细节可以参考RFC文档。

DHCP uses UDP as its transport protocol. DHCP messages from a client

to a server are sent to the ‘DHCP server’ port (67), and DHCP

messages from a server to a client are sent to the ‘DHCP client’ port

(68). A server with multiple network address (e.g., a multi-homed

host) MAY use any of its network addresses in outgoing DHCP messages.

我在排错过程中也用到了这篇文章。

Virtual Machine Cannot Get DHCP IP Address

Just a quick post. When virtual machine cannot get DHCP IP address the first thing you want to check is firewall. Whatever Windows firewall or physical firewall. You should make sure UDP port 67 and 68 are not blocked. Otherwise you will see the virtual machine gets 169.x.x.x IP address only.

The two ports is required for DHCP client to query IP addresses. The methodology is introduced in RFC document.

DHCP uses UDP as its transport protocol. DHCP messages from a client
to a server are sent to the ‘DHCP server’ port (67), and DHCP
messages from a server to a client are sent to the ‘DHCP client’ port
(68). A server with multiple network address (e.g., a multi-homed
host) MAY use any of its network addresses in outgoing DHCP messages.

I also got some ideas in this post.

Network Latency on Virtual Machine

Slight network latency may cause application problem on sensitive virtual machines. Even the network responding time is just 3 or 7 ms. There is a way to improve the stability of responding latency – Enable RSS on NIC.

Network traffic is handled by single CPU core when RSS is disabled. Enable it will distribute the workload to 4 cores by default. You can increase CPU for RSS by change registry.

To summarize the solution. Go to Device Manager -> NIC properties -> Advance -> Find RSS option and enable it. You will see 2 – 3 network drops when applying it.

You can refer following articles for detail.

Poor network performance or high network latency on Windows virtual machines

Virtual Receive-side Scaling in Windows Server 2012 R2

Regarding increase CPU for RSS. Read following article to learn how to modify it.

Setting the Number of RSS Processors