Skip to content

Commit c537037

Browse files
author
Jacob Halsey
committed
correct mistake in docs
1 parent 9964d22 commit c537037

File tree

2 files changed

+106
-29
lines changed

2 files changed

+106
-29
lines changed

‎docs/ROUTING.md

Lines changed: 106 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,7 @@
11
# Fixing Route Table for WSL2
22

3+
This guide applies to Cisco AnyConnect in environments where it has been configured to block split-tunneling.
4+
35
## Step #1 - WSL2 Internet Access
46

57
First you need to ensure your WSL2 distributions can access the internet. Before connecting to the VPN your routes for
@@ -8,24 +10,25 @@ WSL2 will look something like (using the `Get-NetAdapter` command in powershell)
810
```
911
ifIndex DestinationPrefix NextHop RouteMetric ifMetric PolicyStore
1012
------- ----------------- ------- ----------- -------- -----------
11-
26 172.31.79.255/32 0.0.0.0 256 5000 ActiveStore
12-
26 172.31.64.1/32 0.0.0.0 256 5000 ActiveStore
13-
26 172.31.64.0/20 0.0.0.0 256 5000 ActiveStore
13+
23 172.24.31.255/32 0.0.0.0 256 5000 ActiveStore
14+
23 172.24.16.1/32 0.0.0.0 256 5000 ActiveStore
15+
23 172.24.16.0/20 0.0.0.0 256 5000 ActiveStore
1416
```
1517

1618
But when you connect to the VPN, AnyConnect adds a non-functional route with a lower metric:
1719

1820
```
19-
26 172.31.79.255/32 0.0.0.0 256 5000 ActiveStore
20-
26 172.31.64.1/32 0.0.0.0 256 5000 ActiveStore
21-
56 172.31.64.0/20 10.17.104.1 1 1 ActiveStore
22-
26 172.31.64.0/20 0.0.0.0 256 5000 ActiveStore
21+
23 172.24.31.255/32 0.0.0.0 256 5000 ActiveStore
22+
23 172.24.16.1/32 0.0.0.0 256 5000 ActiveStore
23+
4 172.24.16.0/20 10.74.112.1 1 1 ActiveStore
24+
23 172.24.16.0/20 0.0.0.0 256 5000 ActiveStore
2325
```
2426

2527
Unfortunately we cannot remove or modify this route because it will be automatically
2628
[replaced by AnyConnect](https://community.cisco.com/t5/vpn/enforcing-the-split-tunnel-only-access/m-p/4390557/highlight/true#M278089).
27-
However, Windows determines the best route by the lowest sum of interface metric + route metric. What we can do is
28-
increase the AnyConnect interface metric:
29+
However, Windows determines the best route by the lowest
30+
[sum of interface metric + route metric](https://docs.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-interface-metric).
31+
What we can do is increase the AnyConnect interface metric:
2932

3033
```powershell
3134
Get-NetAdapter | Where-Object {$_.InterfaceDescription -Match "Cisco AnyConnect"} | Set-NetIPInterface -InterfaceMetric 6000
@@ -34,15 +37,12 @@ Get-NetAdapter | Where-Object {$_.InterfaceDescription -Match "Cisco AnyConnect"
3437
Now the route table will allow WSL2's NAT connection to the Internet, because 5256 is a lower metric than 6001:
3538

3639
```
37-
26 172.31.79.255/32 0.0.0.0 256 5000 ActiveStore
38-
26 172.31.64.1/32 0.0.0.0 256 5000 ActiveStore
39-
56 172.31.64.0/20 10.17.104.1 1 6000 ActiveStore
40-
26 172.31.64.0/20 0.0.0.0 256 5000 ActiveStore
40+
23 172.24.31.255/32 0.0.0.0 256 5000 ActiveStore
41+
23 172.24.16.1/32 0.0.0.0 256 5000 ActiveStore
42+
4 172.24.16.0/20 10.74.112.1 1 6000 ActiveStore
43+
23 172.24.16.0/20 0.0.0.0 256 5000 ActiveStore
4144
```
4245

43-
(Unfortunately we still cannot connect from Windows to WSL2 via its IP address because AnyConnect blocks this at the
44-
firewall level using Windows Filtering Platform)
45-
4646
## Step #2 - Automation
4747

4848
The AnyConnect metric will unfortunately be reset every time the VPN is started, so we need to automate this fix
@@ -61,24 +61,101 @@ Open task scheduler and click "Create task":
6161

6262
## Step #3 - Working Windows DNS
6363

64-
The above fix then leads to a problem for the Windows host, when we look at the routes to the internet the AnyConnect
65-
adapter (56) now has a higher metric than Wi-Fi (17) and Ethernet (13):
64+
The above fix then leads to a problem for the Windows host - the interface metric is also used by Windows to determine
65+
the ordering of DNS servers. As a result the VPN adapter now has the lowest priority DNS:
66+
67+
```powershell
68+
PS C:\Users\jdhalsey> Get-NetIPInterface | Where-Object {$_.ConnectionState -eq 'Connected'} | Sort-Object -Property InterfaceMetric
69+
70+
ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp ConnectionState PolicyStore
71+
------- -------------- ------------- ------------ --------------- ---- --------------- -----------
72+
23 vEthernet (WSL) IPv4 1500 15 Disabled Connected ActiveStore
73+
23 vEthernet (WSL) IPv6 1500 15 Enabled Connected ActiveStore
74+
13 Ethernet IPv4 1500 25 Enabled Connected ActiveStore
75+
13 Ethernet IPv6 1492 25 Enabled Connected ActiveStore
76+
17 Wi-Fi IPv6 1492 50 Enabled Connected ActiveStore
77+
17 Wi-Fi IPv4 1500 50 Enabled Connected ActiveStore
78+
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected ActiveStore
79+
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
80+
4 Ethernet 2 IPv6 1300 6000 Enabled Connected ActiveStore
81+
4 Ethernet 2 IPv4 1300 6000 Disabled Connected ActiveStore
82+
```
83+
84+
Windows will try the IPv6 and IPv4 DNS servers on both your Ethernet and Wi-Fi first, even though they are unreachable
85+
due to the VPN. Depending on how many servers are configured this can add long delays to DNS resolution, for example:
86+
87+
![](./dns.png)
88+
89+
You can verify this by running `nslookup google.com`, you should see that it attempts to use the first DNS server of
90+
whichever interface has the lowest metric, in this case your Ethernet adapter, and therefore will fail when connected
91+
to the AnyConnect VPN.
92+
93+
You therefore need to update the interface metrics on your Ethernet and Wi-Fi adapters to be greater than the VPN,
94+
for both IPv4 and IPv6. You can use:
95+
96+
```powershell
97+
Set-NetIPInterface -InterfaceAlias "Ethernet" -InterfaceMetric 6025
98+
Set-NetIPInterface -InterfaceAlias "Wi-Fi" -InterfaceMetric 6050
99+
```
100+
101+
(Or alternatively: Control Panel -> Network and Sharing Center -> Change adapter settings -> Ethernet Properties ->
102+
Internet Protocol Version 4/6 -> Advanced -> Interface Metric)
103+
104+
The interface ordering should now look like:
66105

106+
```powershell
107+
PS C:\Users\jdhalsey> Get-NetIPInterface | Where-Object {$_.ConnectionState -eq 'Connected'} | Sort-Object -Property InterfaceMetric
108+
109+
ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp ConnectionState PolicyStore
110+
------- -------------- ------------- ------------ --------------- ---- --------------- -----------
111+
23 vEthernet (WSL) IPv6 1500 15 Enabled Connected ActiveStore
112+
23 vEthernet (WSL) IPv4 1500 15 Disabled Connected ActiveStore
113+
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected ActiveStore
114+
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
115+
4 Ethernet 2 IPv4 1300 6000 Disabled Connected ActiveStore
116+
4 Ethernet 2 IPv6 1300 6000 Enabled Connected ActiveStore
117+
13 Ethernet IPv6 1492 6025 Enabled Connected ActiveStore
118+
13 Ethernet IPv4 1500 6025 Enabled Connected ActiveStore
119+
17 Wi-Fi IPv6 1492 6050 Enabled Connected ActiveStore
120+
17 Wi-Fi IPv4 1500 6050 Enabled Connected ActiveStore
67121
```
68-
56 0.0.0.0/0 10.17.104.1 1 6000 ActiveStore
69-
17 0.0.0.0/0 10.2.9.254 0 50 ActiveStore
70-
13 0.0.0.0/0 10.2.9.254 0 25 ActiveStore
122+
123+
You can verify this is working by running `nslookup google.com`, you should see a successful request to the address
124+
of the VPN DNS server.
125+
126+
## WSL2 <-> Host Communication
127+
128+
In step #1 we modified the route metrics such that WSL should in theory now be reachable:
129+
130+
```powershell
131+
PS C:\Users\jdhalsey> Find-NetRoute -RemoteIPAddress "172.24.18.66" | select InterfaceAlias
132+
133+
InterfaceAlias
134+
--------------
135+
vEthernet (WSL)
136+
vEthernet (WSL)
71137
```
72138

73-
This will cause Windows to attempt to connect to the now inaccessible DNS servers on Ethernet and Wi-Fi first, causing
74-
up to a 10-second delay in DNS resolution. The solution is to manually update the network interfaces to have a higher
75-
metric than the AnyConnect interface.
139+
Yet if we launch an HTTP server in WSl2:
76140

77-
Set the Ethernet and Wi-Fi metrics to 6025 and 6050 to ensure they have lower priority than the AnyConnect route (6001)
78-
(Control Panel -> Network and Sharing Center -> Change adapter settings -> Ethernet Properties -> Internet Protocol Version 4 -> Advanced)
141+
```bash
142+
python3 -m http.server 8000
143+
```
144+
145+
And attempt to connect to it whilst AnyConnect is running, it will fail:
79146

147+
```powershell
148+
PS C:\Users\jdhalsey> curl.exe http://172.24.18.66:8000
149+
curl: (7) Failed to connect to 172.24.18.66 port 8000 after 0 ms: Bad access
80150
```
81-
56 0.0.0.0/0 10.17.104.1 1 6000 ActiveStore
82-
17 0.0.0.0/0 10.2.9.254 0 6050 ActiveStore
83-
13 0.0.0.0/0 10.2.9.254 0 6025 ActiveStore
151+
152+
The reason for this is that AnyConnect is blocking communication at the firewall level, unfortunately this is
153+
implemented using a Windows Filtering Platform kernel level driver, so it cannot easily be disabled.
154+
155+
Fortunately if you are on [WSL 18970](https://docs.microsoft.com/en-us/windows/wsl/release-notes#build-18970) or newer
156+
you can use the localhost relay to work around this:
157+
158+
```powershell
159+
PS C:\Users\jdhalsey> curl.exe http://localhost:8000
160+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
84161
```

‎docs/dns.png

8.77 KB
Loading

0 commit comments

Comments
 (0)