Lost access to local network after using VPN program

This is a weird one for sure. Last month, I was testing a VPN program (Cisco QuickConnect) for a customer to make sure that their setup works. Ultimately, the test was semi-successful, and we ended up pointing them in a different direction for VPN, but I lost access to all network resources on my laptop's Ethernet interface after that experiment. Here are the specifics of the symptoms:

• Cannot ping the default gateway at my home office (192.168.1.1) any longer
• Can ping an address on the Internet
• Cannot resolve domain names
• The wireless interface on the same is not affected, and is my only way to be able to use this network from this computer now
• As the problem started to occur, some applications were still able to get out to the Internet, (assuming that they still had an active session of some kind going on) but others were not
• No websites can be reached by name or by IP address

I uninstalled QuickConnect right away after this incident and tried again. No change. Tried clearing the Windows routing table. No change. Did a system restore to the time right before the offending program was installed (it was at least nice enough to create a restore point prior to installation). Still no change. Tried reinstalling the Ethernet driver as well. This also was ineffective.

To make a bizarre problem even stranger, this only happens on networks with the same subnet (192.168.1.0/24) that I was trying to connect to and from when the problem first occurred. Others are 100% fine and I can work all day long with the same Ethernet card on any other subnet.
I checked to make sure that no static IP addressing, DNS, or anything strange like that had been set by the VPN program. None had. Any ideas?

samuria said:

Open a cmd prompt type
Ipconfig /all

Tracert adobe.com
Tracert 1.1.1.1
Post all results

Here are my tracert results: (kinda weird!)

Code:

tracert adobe.com
  Unable to resolve target system name adobe.com.

Code:

tracert 1.1.1.1
Tracing route to 1.1.1.1 over a maximum of 30 hops

  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
  3    10 ms    28 ms    22 ms  96.34.43.237
  4    12 ms    15 ms    15 ms  96.34.36.84
  5    13 ms    17 ms    29 ms  96.34.32.34
  6    10 ms    13 ms    14 ms  96.34.2.8
  7    16 ms    23 ms    23 ms  96.34.0.139
  8    17 ms    19 ms    19 ms  96.34.3.9
  9    29 ms    32 ms    21 ms  208.115.136.180
 10    17 ms    21 ms    19 ms  1.1.1.1

Trace complete.

After examining the results of my "ipconfig /all," I noticed that a "DNS Suffix Search list" consisting of "cisco" and "cisco" had been appended to the configuration. Unfortunately, removing this had no effect. The problem still persists after a restart:

Code:

ipconfig /all
Windows IP Configuration

   Host Name . . . . . . . . . . . . : LaptopComputer4
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Gigabit Controlle
r
   Physical Address. . . . . . . . . : 00-26-B9-04-E6-FD
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::d02:71e:bdd6:61a0%26(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.122(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, November 23, 2020 7:20:19 PM
   Lease Expires . . . . . . . . . . : Tuesday, November 24, 2020 7:20:19 PM
   Default Gateway . . . . . . . . . : 192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6 IAID . . . . . . . . . . . : 184559289
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-20-23-37-7A-00-26-B9-04-E6-FD

   DNS Servers . . . . . . . . . . . : 192.168.1.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Wireless LAN adapter Wireless Network Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Dell Wireless 1510 Wireless-N WLAN Mini-C
ard
   Physical Address. . . . . . . . . : 0C-60-76-78-99-F1
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Ethernet adapter VMware Network Adapter VMnet8:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
8
   Physical Address. . . . . . . . . : 00-50-56-C0-00-08
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::c581:29f8:6227:2f50%15(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.140.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 469782614
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-20-23-37-7A-00-26-B9-04-E6-FD

   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{FE9F7824-8B34-4BC6-A551-D575E96BEBFC}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{8CB4BF7D-E4E6-4729-AC6A-A6C2EF98DEF9}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{3C674CC2-87E5-4501-8B35-C7B03C9A043F}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Just to see what would happen, I tried statically addressing that interface... and it worked! If I statically address this computer on this subnet, the problem completely goes away. Flipping back to DHCP, it reliably returns. I'm completely stumped on this.

I'm thinking you have a TCP/IP stack issue. Though, you'd think a system restore would have brought that back from before the VPN was installed.

If you haven't entered all of these commands, I have instructions on resetting the crap out of the TCP/IP stack and created a batch file to do all that in one go and made that batch file in an .EXE. You can find these instructions at my website here. I have a pretty tight lid on security so a VPN may get blocked among other things.

Also, try disabling and enabling all network adapters one at a time. Including VMware's NICs. Speaking of VMware, you should have ran this VPN in there first for testing. That's what I do when I'm testing stuff that I don't know how it will play on my host.

Now here's something interesting. Here's what one of my VMware NICs says (edited for privacy).

Code:

Ethernet adapter VMware Network Adapter VMnet1:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
1
   Physical Address. . . . . . . . . : 00-50-56-
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80(Preferred)
   Autoconfiguration IPv4 Address. . : 169.254.122.105(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 45
   DHCPv6 Client DUID. . . . . . . . : 00-

Your IPv4 looks different than mine and is not a local class B private IP address.

F22 Simpilot said:

Also, try disabling and enabling all network adapters one at a time. Including VMware's NICs. Speaking of VMware, you should have ran this VPN in there first for testing. That's what I do when I'm testing stuff that I don't know how it will play on my host.

I certainly won't make that mistake next time. For testing questionable software, the Virtual Machine is my go-to. I thought that with it being a trustworthy-sounding vendor, (Cisco) I wouldn't have to worry about something this crazy happening, but apparently I was quite wrong.

F22 Simpilot said:

I'm thinking you have a TCP/IP stack issue. Though, you'd think a system restore would have brought that back from before the VPN was installed.

I concur. It was too long ago for me to remember if it errored out or anything, but I thought I would've remembered that if it did.

F22 Simpilot said:

If you haven't entered all of these commands, I have instructions on resetting the crap out of the TCP/IP stack and created a batch file to do all that in one go and made that batch file in an .EXE. You can find these instructions at my website here. I have a pretty tight lid on security so a VPN may get blocked among other things.

Thanks for the tips. I've done some, but certainly not all of, those. Unfortunately, even after performing each one and restarting, the problem persists the same as before. No luck even after disabling/re-enabling all of the other network adapters.

F22 Simpilot said:

Now here's something interesting. Here's what one of my VMware NICs says (edited for privacy).

Code:

Ethernet adapter VMware Network Adapter VMnet1:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
1
   Physical Address. . . . . . . . . : 00-50-56-
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80(Preferred)
   Autoconfiguration IPv4 Address. . : 169.254.122.105(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 45
    DHCPv6 Client DUID. . . . . . . . : 00-

Your IPv4 looks different than mine and is not a local class B private IP address.

I'm not sure exactly why that is. The virtual machines get networked just fine. I do have my virtual machines configured for Bridged mode instead of Nat, however. Not sure if this makes a difference.

Incidentally, in this mode, even with the host computer not being able to reach stuff on the network, the virtual machine has no trouble.

samuria said:

The test shows you get out ok as the trace goes to 1.1.1.1 ok what it does show is the dns isnt working as you cant reach adobe.com set your dns to 1.1.1.1 & 1.0.0.1 on all interfaces

I can set my DNS to anything, but the computer is still unable to reach 192.168.1.1 or any IP addresses on the local subnet while in this glitched state.

Channel2012 said:

I'm not sure exactly why that is. The virtual machines get networked just fine. I do have my virtual machines configured for Bridged mode instead of Nat, however. Not sure if this makes a difference.

Ah, that's probably why. In bridge mode you share the NIC of the host, thus probably that class of IP address.

Channel2012 said:

Incidentally, in this mode, even with the host computer not being able to reach stuff on the network, the virtual machine has no trouble.

That's an interesting piece of Info. there. I'm wondering if perhaps there's some Cisco VPN remnant left over like a service or driver causing the host to have issues. I'd do two things: run though all of your services looking for something that might be that VPN related and use Autoruns to look for any Cisco remnants. It might help to be in the Everything tab of Autorun and in the search box just search for Cisco. Not sure if caps would matter though. And for the heck of it, run lspfix.

LSP-Fix - a free program to repair damaged Winsock 2 stacks

Autoruns for Windows - Windows Sysinternals | Microsoft Docs

As always, scan all downloads at Virus Total.

samuria said:

try this app on all pcs can it see local network and who is master browser?
https://www.nirsoft.net/utils/netbios_scanner.html


Are all pcs in same workgroup?

Yes. All other computers show up fine when on the wireless network, and none show up in the scan when on the wired with DHCP. From another computer, the results are comparable (no response from the computer in question when exclusively on wired with DHCP; responds normally when on wireless or statically addressed on the wired network).

F22 Simpilot said:

Ah, that's probably why. In bridge mode you share the NIC of the host, thus probably that class of IP address.



That's an interesting piece of Info. there. I'm wondering if perhaps there's some Cisco VPN remnant left over like a service or driver causing the host to have issues. I'd do two things: run though all of your services looking for something that might be that VPN related and use Autoruns to look for any Cisco remnants. It might help to be in the Everything tab of Autorun and in the search box just search for Cisco. Not sure if caps would matter though. And for the heck of it, run lspfix.

LSP-Fix - a free program to repair damaged Winsock 2 stacks

Autoruns for Windows - Windows Sysinternals | Microsoft Docs

As always, scan all downloads at Virus Total.

I scoured services, but didn't see anything related to that program. I also have Cisco AnyConnect for my day job, as well as some Cisco DRM software installed for watching DirecTV, so there are other Cisco services, but none of them seem to be related to QuickConnect. Same goes for AutoRuns. Nothing Cisco, or otherwise, looked terribly out of the ordinary to me.

Finally, I tried LSP-Fix. It was not able to identify any problems.