General Failure when pinging hostname while on VPN

[PeterLMSD]

Hardware: HP EliteBook 840 G6 (works) and EliteBook 840 G8 (doesn't work)  
OS: Windows 10 22H2
ASA: ASA 5505 9.2(4) 33 as well as 2130 Firepower with ASA 9.18.3
VPN: SSL VPN (not IPSec) with split tunneling for Azure, but still happens with tunneling all traffic.

I have been debugging an issue for quite some time with newer model HP Laptops (840 G8 and newer) and am unsure if this is impacting other OEMs.
When I am working remotely and connecting via AnyConnect I am unable to ping the local computer name as the DNS resolution resolves to the home internet IP rather than the VPN tunnel IP once the session comes up.

This did not happen on a HP EliteBook 840 G6, but does happen on the G8 and other newer models.

EliteBook 840 G6:
Home Internet LAN IP: 192.168.1.10
VPN Tunnel Interface IP: 10.1.1.50

C:\Users\testuser>hostname
TESTG6

C:\Users\testuser>ping TESTG6 -4
Pinging TESTG6.org.nz [10.1.1.50] with 32 bytes of data:
Reply from 10.1.1.50: bytes=32 time<1ms TTL=128
Reply from 10.1.1.50: bytes=32 time<1ms TTL=128

But doing the same on the HP EliteBook G8 I get:
EliteBook 840 G8:
Home Internet LAN IP: 192.168.1.11
VPN Tunnel Interface IP: 10.1.1.51

C:\Users\testuser>hostname
TESTG8

C:\Users\testuser>ping TESTG8 -4
Pinging TESTG8.org.nz [192.168.1.11] with 32 bytes of data:
General failure.
General failure.

As you can see above for whatever reason the G8 is resolving the Home Internet LAN IP rather than the VPN Tunnel Interface IP that is allocated when the VPN tunnel comes up.

I can ping the VPN Tunnel Interface IP (ie 10.1.1.x) when the VPN session is up, but the hostname resolution always seems to resolve to the Home Internet LAN IP not the VPN Tunnel Interface IP on the G8's and not the G6's.

It's also important to add the "-4" to the end of the ping statement after the hostname as that will force ping to use IPv4 rather than it defaulting to IPv6, which I think is the problem observed in the AnyConnect disables native IPv6 post below.

This applies to pinging the plain hostname (ie TESTG8) and the FQDN based on the AD domain which is the primary DNS suffix (ie TESTG8.org.nz).

Updating the windows local hosts file in C:\windows\system32\drivers\etc\hosts to have the VPN Tunnel Interface IP doesn't work either. Nor does doing a "ipconfig /flushdns" fix it.

What does fix it is when testing using the built in HP Wireless adapter, or using ethernet on a HP USB-C Thunderbolt dock it doesn't work, but when using either the built in 4G Wireless WAN adapter or a 3rd party USB-A Ethernet (StarTech USB31000S) or Wireless (TP-Link TL-WN821N) adapter then it works fine on the G8s.

Additionally when testing via USB-C Thunderbolt on the HP Thunderbolt Dock G4 or HP USB-C Dock G5 then the G6 works and the G8 does not work. Even though the Thunderbolt connection is exactly the same, and the drivers on both laptops are exactly the same.

Have tried many things on the G8 including various versions of the AnyConnect 4.10.x Client and the Secure Client 5.x, a vanilla Windows 10 22H2 vs the organisations standard SCCM deployed image, out of the box drivers from Windows, the latest drivers installed by Windows Update on the vanilla image, all the latest drivers from HP for the G8, the even newer drivers from Intel (Wireless - Intel Wi-Fi 6 AX201) and Realtek (USB-C Thunderbolt - Realtek USB Ethernet Adapter) all without success. The only fix was to use USB-A connected 3rd party wired or wireless adapters, or the built in Intel XMM 7360 4G/LTE WWAN adapter.

I can see some similar posts about this issue:

https://community.cisco.com/t5/vpn/cisco-anyconnect-ping-general-failure/td-p/2417563

https://community.cisco.com/t5/vpn/general-failure-pinging-host-name-while-on-vpn/td-p/3059612

https://community.cisco.com/t5/vpn/anyconnect-disables-native-ipv6-when-connected/td-p/1748824

But this could be hardware related and was wanting to know if anyone else was seeing this issue on different hardware OEMs (Lenovo, Toshiba, Dell etc?)

[PeterLMSD · Accepted solution]

A further update to this. HP have provided a fix and it is related to Modern Standby and how the Cisco (and any VPN Client as this problem also impacts Fortigate SSL VPN). If your machine supports Modern Standby then you will most likely have the problem. Using powercfg /a if you are in S0 mode that is Modern Standby and S3 is not.

powercfg /a
The following sleep states are available on this system:
    Standby (S0 Low Power Idle) Network Connected
    Hibernate

The following sleep states are not available on this system:
    Standby (S1)
        The system firmware does not support this standby state.
        This standby state is disabled when S0 low power idle is supported.

    Standby (S2)
        The system firmware does not support this standby state.
        This standby state is disabled when S0 low power idle is supported.

    Standby (S3)
        This standby state is disabled when S0 low power idle is supported.

    Hybrid Sleep
        Standby (S3) is not available.

    Fast Startup
        This action is disabled in the current system policy.

To work-around this issue you must disable the "NS offload" or "NS offload for WoWLAN" setting on every network adapter that typically is built into the machine such as the WiFi and USB-C Ethernet adapters. This is also why any adapters that are plugged in are not impacted as they won't be leveraging modern standby.
This may have implications on power usage but at least you can now work on VPN. Once it has been disabled you should notice that ping starts working and resolving the correct hostname.