Blog: TCP/IP

We had a customer create a task for a handful of users not being able to access the company's file server while working from home. The IT Director at this company used to work for aa different customer and had just recently moved to this company and inherited this network. After talking to him about this server, he said the IP address of the file server was 192.168.1.1. There were also a few other servers some people had trouble accessing at times, but the file server was the main server they needed. The issue was obvious in that the file server has the same IP address as many home routers.

The customer has a Cisco ASA, so I tired to setup AnyConnect to NAT the traffic across AnyConnect. I setup a twice NAT across the AnyConnect VPN tunnel, but when the DNS server replied with the IP addresses, the replies were not NAT'd. The solution to this is DNS Doctoring, but DNS Doctoring only works with object NAT so this did not work. We could have setup these users to connect to a different IP address when offsite so DNS Doctoring was not needed, but this did not seem like a good solution.

Cisco documentation on NAT across AnyConnect VPN tunnel: https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115753-dns-doctoring-asa-config.html

The main user that was having this issue while out of town returned home so this issue became less of a priority. Ultimately, the solution is to change their internal IP scheme to not use the 192.168.1.0/24 or any other common IP subnet. The short-term work around for this customer should we need to do this again before we change the IP scheme will be to use RD Gateway and have users connect that way instead of via AnyConnect.


 

A client of ours uses the Cybernet iONE all in one PCs for customer internet stations at several of their locations. One oddity of these machines is that they ship with dual Gigabit onboard NICs. On these internet stations we typically use just one and disable the other NIC. While building out a particular machine, I needed to install several pieces of software that we deploy via Group Policy Software Installation. The problem is that any time I would attempt to deploy the software via Group Policy, it would fail and I would see event ID 1054 in the event logs… “Windows cannot obtain the domain controller name for the computer network. (The specified domain either does not exist or exist or could not be contacted). Group Policy processing aborted. Data: (unavailable)”.  Everything else was working fine. The machine was a member of the domain, I could ping the domain controller that DHCP had assigned to the machine, I could resolve internal and external addresses, gpresult showed that the PC was successfully linked to the software installation OU, etc. [more]

After conducting some research on this error and on these machines, it turns out the problem was that the onboard Broadcom gigabit NIC was taking too long to auto-negotiate its link speed, creating a “race condition” between the TCP/IP protocol and the NIC driver when they try and register with the MS Nework Driver Interface Specification. The local Userenv process (what actually performs GP’s instructions) would attempt to install the software before the NIC was fully available, thereby causing it to fail when it would attempt to run the assigned MSI over the network. Here’s how to rig the race so that the NIS driver always wins the “race”. There is a MS hotfix available for this along with a more detailed problem description at http://support.microsoft.com/kb/840669. After installing this hotfix you must add the DWORD registry entry GpNetworkStartTimeoutPolicyValue in  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon and set the value of that DWORD entry to the number of seconds you would like the OS to delay processing Group Policy Startup scripts.