Thanks for the routing table. I think it lines up with John's assumption that Split Tunnel is not enabled on your VPN provider. That is, the VPN client, when establishing a connection to the VPN server, is configured to update the operating system's routing table and move all traffic through the VPN.
You mention the following hosts being unreachable:
- 172.27.0.1 (Unreachable)
- 192.168.2.1 (Unreachable)
- 172.28.48.1 (Unreachable)
- 172.22.128.1 (Unreachable)
172.27.0.1
This is IP is given as the default gateway for your Cisco AnyConnect interface:
Ethernet adapter Ethernet 2:
Description . . . . . . . . . . . : Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
...
IPv4 Address. . . . . . . . . . . : 172.27.31.15(Preferred)
Default Gateway . . . . . . . . . : ::
172.27.0.1
That you cannot ping this particular IP address is likely just a firewall rule on the server side that prevents ICMP (ping) traffic. If it were truly unreachable then you would not have any connectivity at all according to state of the route table.
192.168.2.1
This is, I'm assuming, the default gateway for a wireless access point that your device is connecting to:
Wireless LAN adapter Wi-Fi:
...
IPv4 Address. . . . . . . . . . . : 192.168.2.13(Preferred)
Default Gateway . . . . . . . . . : 192.168.2.1
...
The relevant pieces from the routing table are:
IPv4 Route Table
=================
Active Routes:
Network Destination Netmask Gateway Interface Metric
192.168.2.0 255.255.255.0 172.27.0.1 172.27.31.15 2
Here, traffic destined for the 192.168.2.0/24 subnet has only one option, to go through the 127.27.0.1 gateway. There is no other route saying to use the 192.168.2.1 Gateway on the 192.168.2.13 Interface.
As such, traffic destined for the 192.168.2.0/24 subnet hits the VPN gateway, and there is nothing on the other side. Hence, destination unreachable.
172.28.48.1
The relevant pieces from the routing table are:
IPv4 Route Table
=================
Active Routes:
Network Destination Netmask Gateway Interface Metric
172.28.48.0 255.255.240.0 On-link 172.28.48.1 271
172.28.48.0 255.255.240.0 172.27.0.1 172.27.31.15 2
Here, you have two different routes for the same network, 172.28.48.0/20. The On-link one is what you want the traffic to go through. However, its Metric is 271, which is higher than the Metric for the VPN gateway, which is 2. The lower metric wins, and so traffic to the 172.28.48.0/20 network goes to the VPN gateway, and there is nothing on the other side. Hence, destination unreachable.
172.22.128.1
The relevant pieces from the routing table are:
IPv4 Route Table
=================
Active Routes:
Network Destination Netmask Gateway Interface Metric
172.22.128.0 255.255.240.0 172.27.0.1 172.27.31.15 2
172.22.128.0 255.255.240.0 On-link 172.22.128.1 271
(This is a similar situation to the 172.28.48.0/20 network.)
For the 172.22.128.0/20 network, two routes are specified. You want the On-link one, but the metric for the VPN gateway is lower. So, traffic for 172.22.128.0/20 goes to the VPN gateway, and there is nothing on the other side. Hence, destination unreachable.
In order for you to reach the desired networks from your host machine, you will need to remove the routes that the Cisco AnyConnect VPN client has installed in the routing table. I do not know whether or not the VPN client will detect this and update them again though; typically, when administrators configure their VPNs this way, it is intentional, and manually trying to work around the VPN client configuration without permission might be viewed negatively.
I also don't think this is a WSL2 vs WSL1 issue, or a Windows 10 vs 11 issue, or a virtual bridge vs virtual NAT issue (but I readily admit I could be mistaken). So long as the routing table on the host is configured this way, any traffic from the host machine is going to go through the VPN rather than to the relevant interfaces on the host machine that would push the traffic to the local VM network.
Your VMs themselves should still have network connectivity; they'll just go through the VPN. If you're able to log into the VMs "locally" via a console log-in, you could confirm that.
