TCP/UDP connections in WSL do not exactly follow the Windows routing table

[segin]

Linux applications do not have their network connections routed in the same way as Windows applications. This causes Linux applications to fail to connect to the Internet when some third-party VPN clients are required to reach the open Internet.

Steps to reproduce:

1. Set up a Linux server with two Ethernet ports. Configure one Ethernet port to connect to the Internet, and the second to provide a separate LAN without Internet access.
2. Install and configure OpenVPN as a server on this Linux server. Have it listen on the LAN-only Ethernet port.
3. Use iptables to route/NAT the subnet OpenVPN uses on it's tun interface through the first Ethernet port so that other machines connected to the second Ethernet port's network segment can reach the Internet if and only if they use a VPN connection to the OpenVPN server.
4. Connect a Windows machine to the LAN of the Linux server's second Ethernet port.
5. Verify that it is not possible to browse the web using Microsoft Edge or Google Chrome, or download from the Windows Store.
6. Install the official OpenVPN for Windows client and install a client configuration for it to connect to the OpenVPN server previously set up. Connect to the OpenVPN server using the client on the Windows machine.
7. Verify that web browsing is now possible with Edge or Chrome, and that the Windows Store works.
8. Start a bash session on the Windows machine using WSL and attempt to access the Internet using Linux programs in that session, e.g. attempting to download a file with wget. Observe that while all of the Windows software is properly obeying the Windows routing tables and being routed through the virtual Ethernet interface of OpenVPN, the Linux software instead has it's connections routed directly through the physical Ethernet interface (which has no Internet access in this case), and thus will summarily fail without exception.

[aseering]

I'm currently using OpenVPN for Windows. I'm not experiencing any routing issues within WSL.

@segin -- could you elaborate on how you know that the reason that your connections are not going through is because of the routing table in particular?

Is it possible that your problem is not with the routing table but with the domain-name resolution? Either way will cause connections to fail with the exact symptoms that your description above lists. If so, could this be the same as #416 ?

[segin]

@aseering -- I believe you might be correct. I double-checked and the autogenerated /etc/resolv.conf in WSL places the "naked" connection's DNS server over that of the OpenVPN connection, which automatically resolves all hostnames to the outside Internet to the local server which runs the OpenVPN server.

I can temporarily work around this by manually editing out those lines from /etc/resolv.conf, but this file will be regenerated to the automatically-generated version at most 10 minutes thereafter.

I will agree that, in this case, this is indeed a duplicate of #416 and I apologise to the Bash on Windows team for having submitted an extraneous bug report.

A possible solution is to allow users to disable automatic /etc/resolv.conf generation.

[jackchammons]

duplicate #416