Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WSL2 with graphics: Browsers and OS do not follow routing #1240

Open
Kenya-West opened this issue Aug 16, 2024 · 4 comments
Open

WSL2 with graphics: Browsers and OS do not follow routing #1240

Kenya-West opened this issue Aug 16, 2024 · 4 comments

Comments

@Kenya-West
Copy link

Kenya-West commented Aug 16, 2024 •
edited
Loading

Problem

Hello! I successfully connect to my VPN with config:

host = <some host>
port = <some port>
username = <some username>
password = <some very unlawful password inspired by the greatest German dream in XX century>
set-dns = 0
pppd-use-peerdns = 0

And I launch the tool by command:

sudo openfortivpn -c ~/openfortivpn.config -o <TOKEN>

It launches fine:

OpenFortiVPN Log 

INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
Using interface ppp0
Connect: ppp0 <--> /dev/pts/11
INFO:   Got addresses: [10.9.0.1], ns [10.1.1.10, 8.8.8.8]
INFO:   Negotiation complete.
INFO:   Got addresses: [10.9.0.1], ns [10.1.1.10, 8.8.8.8]
INFO:   Negotiation complete.
INFO:   Got addresses: [10.9.0.1], ns [10.1.1.10, 8.8.8.8]
INFO:   Negotiation complete.
INFO:   Negotiation complete.
local  IP address 10.9.0.1
remote IP address 169.254.2.1
INFO:   Interface ppp0 is UP.
INFO:   Setting new routes...
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
WARN:   Route to gateway exists already.
INFO:   Tunnel is up and running.

But unfortunately browsers and entire OS (Ubuntu) do not respect the routes, which are:

Additional logs

ip route show:

Details 

default via 172.30.96.1 dev eth0
10.1.1.10/31 dev ppp0 scope link
10.32.2.0/24 dev ppp0 scope link
10.32.2.99 dev ppp0 scope link
10.32.3.12 dev ppp0 scope link
10.32.3.19 dev ppp0 scope link
10.32.3.47 dev ppp0 scope link
10.32.3.60 dev ppp0 scope link
10.32.3.61 dev ppp0 scope link
10.32.3.62 dev ppp0 scope link
10.32.3.63 dev ppp0 scope link
10.32.3.64 dev ppp0 scope link
10.32.3.66 dev ppp0 scope link
10.32.3.96 dev ppp0 scope link
10.32.4.11 dev ppp0 scope link
10.32.4.21 dev ppp0 scope link
10.32.4.31 dev ppp0 scope link
10.32.4.48 dev ppp0 scope link
10.32.4.49 dev ppp0 scope link
10.32.4.63 dev ppp0 scope link
10.32.4.78 dev ppp0 scope link
10.32.4.116 dev ppp0 scope link
10.32.6.7 dev ppp0 scope link
10.32.6.26 dev ppp0 scope link
10.32.6.32 dev ppp0 scope link
10.32.6.35 dev ppp0 scope link
10.32.6.42 dev ppp0 scope link
10.32.6.44 dev ppp0 scope link
10.32.6.49 dev ppp0 scope link
10.32.6.57 dev ppp0 scope link
10.32.6.67 dev ppp0 scope link
10.32.6.81 dev ppp0 scope link
10.32.6.84 dev ppp0 scope link
10.32.6.86 dev ppp0 scope link
10.32.6.90 dev ppp0 scope link
10.32.6.96 dev ppp0 scope link
10.32.6.106 dev ppp0 scope link
10.32.6.114 dev ppp0 scope link
10.32.6.127 dev ppp0 scope link
10.32.6.137 dev ppp0 scope link
10.32.6.138/31 dev ppp0 scope link
10.32.6.140/31 dev ppp0 scope link
10.32.6.142 dev ppp0 scope link
10.32.6.161 dev ppp0 scope link
10.32.6.162/31 dev ppp0 scope link
10.32.6.165 dev ppp0 scope link
10.32.6.166 dev ppp0 scope link
10.32.6.173 dev ppp0 scope link
10.32.6.181 dev ppp0 scope link
10.32.6.200 dev ppp0 scope link
10.32.6.201 dev ppp0 scope link
10.32.6.202 dev ppp0 scope link
10.32.6.203 dev ppp0 scope link
10.32.6.207 dev ppp0 scope link
10.32.6.230 dev ppp0 scope link
10.32.6.236 dev ppp0 scope link
10.32.6.241 dev ppp0 scope link
10.32.6.242 dev ppp0 scope link
10.32.6.243 dev ppp0 scope link
10.32.6.246 dev ppp0 scope link
10.32.7.0/24 dev ppp0 scope link
10.32.8.20 dev ppp0 scope link
10.32.9.20 dev ppp0 scope link
10.33.3.0/24 dev ppp0 scope link
10.42.1.30 dev ppp0 scope link
10.42.1.80 dev ppp0 scope link
10.42.3.31 dev ppp0 scope link
10.42.3.201 dev ppp0 scope link
10.77.3.10 dev ppp0 scope link
<FORTINET VPN SERVER> via 172.30.96.1 dev eth0
169.254.2.1 dev ppp0 proto kernel scope link src 10.9.0.1
172.30.96.0/20 dev eth0 proto kernel scope link src 172.30.98.123
192.168.0.72 dev ppp0 scope link
192.168.0.250 dev ppp0 scope link
192.168.1.205 dev ppp0 scope link
192.168.3.190 dev ppp0 scope link
192.168.3.211 dev ppp0 scope link

And the active interface is still eth0, which is fine:

ip route | grep default
default via 172.30.96.1 dev eth0
All interfaces when OpenFortiVPN is on 

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 10.255.255.254/32 brd 10.255.255.254 scope global lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:ca:31:5b brd ff:ff:ff:ff:ff:ff
    inet 172.30.98.123/20 brd 172.30.111.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:feca:315b/64 scope link
       valid_lft forever preferred_lft forever
12: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1354 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp
    inet 10.9.0.1 peer 169.254.2.1/32 scope global ppp0
       valid_lft forever preferred_lft forever

OpenFortiVPN logs by --verbose flag:

Details 

INFO:   Negotiation complete.
DEBUG:  pppd ---> gateway (6 bytes)
local  IP address 10.9.0.4
remote IP address 169.254.2.1
DEBUG:  Got Address: 10.9.0.4
DEBUG:  Interface Name: ppp0
DEBUG:  Interface Addr: 10.9.0.4
INFO:   Interface ppp0 is UP.
INFO:   Setting new routes...
DEBUG:  ip route show to 0.0.0.0/0.0.0.0 dev !ppp0
DEBUG:  ip route show to <FORTINET VPN SERVER IP ADDRESS>/255.255.255.255 dev ppp0
DEBUG:  Route not found.
DEBUG:  ip route show to <FORTINET VPN SERVER IP ADDRESS>/255.255.255.255 dev !ppp0
DEBUG:  Setting route to vpn server...
DEBUG:  ip route show to <FORTINET VPN SERVER IP ADDRESS>/255.255.255.255 via 172.30.96.1 dev eth0
DEBUG:  ip route add to <FORTINET VPN SERVER IP ADDRESS>/255.255.255.255 via 172.30.96.1 dev eth0
DEBUG:  ip route add to 10.32.6.81/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.84/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.1.1.10/255.255.255.254 dev ppp0
DEBUG:  ip route add to 10.42.3.31/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.77.3.10/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.162/255.255.255.254 dev ppp0
DEBUG:  ip route add to 10.32.6.161/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.3.12/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.42.1.30/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.2.99/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.96/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.44/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.49/255.255.255.255 dev ppp0
DEBUG:  ip route add to 192.168.0.250/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.86/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.162/255.255.255.254 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.6.161/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.2.0/255.255.255.0 dev ppp0
DEBUG:  ip route add to 10.32.8.20/255.255.255.255 dev ppp0
DEBUG:  ip route add to 192.168.0.72/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.67/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.57/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.26/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.42.1.30/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.6.86/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.3.66/255.255.255.255 dev ppp0
DEBUG:  ip route add to 192.168.0.250/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.6.49/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.6.127/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.3.19/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.181/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.2.0/255.255.255.0 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.6.7/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.81/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.6.90/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.2.99/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.1.1.10/255.255.255.254 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.6.173/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.142/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.140/255.255.255.254 dev ppp0
DEBUG:  ip route add to 10.32.6.138/255.255.255.254 dev ppp0
DEBUG:  ip route add to 10.32.6.42/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.42.1.80/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.4.21/255.255.255.255 dev ppp0
DEBUG:  ip route add to 192.168.0.72/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 192.168.1.205/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.4.31/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.44/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 192.168.3.211/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.3.60/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.3.61/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.3.62/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.3.63/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.3.64/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.7.0/255.255.255.0 dev ppp0
DEBUG:  ip route add to 10.32.4.11/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.114/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.42.3.201/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.4.48/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.246/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.3.47/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.106/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.230/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.32/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.3.96/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.35/255.255.255.255 dev ppp0
DEBUG:  ip route add to 192.168.3.190/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.33.3.0/255.255.255.0 dev ppp0
DEBUG:  ip route add to 10.32.6.207/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.242/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.166/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.203/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.200/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.201/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.202/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.241/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.243/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.4.63/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.4.78/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.4.116/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.165/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.236/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.4.49/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.32.6.137/255.255.255.255 dev ppp0
DEBUG:  ip route add to 10.42.3.31/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.6.207/255.255.255.255 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.32.9.20/255.255.255.255 dev ppp0
INFO:   Tunnel is up and running.

DNS config 

 cat /etc/resolv.conf -p
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 10.255.255.254

Do not really understand what it does, but here is IP address of ppp0 interface 

 ip addr show ppp0
12: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1354 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp
    inet 10.9.0.1 peer 169.254.2.1/32 scope global ppp0
       valid_lft forever preferred_lft forever

Testing other solutions

I tried to make ping and tracert through ppp0 interface, but none succeed, 100% packet loss and did not reach destination.

ping 10.32.6.7

--- 10.32.6.7 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3093ms
sudo traceroute -i ppp0 10.32.6.7
traceroute to 10.32.6.7 (10.32.6.7), 30 hops max, 60 byte packets
 1  * * *
...
30  * * *

What I know

  • Routing is OK
  • DNS is fine

And yet entire OS can't access 10.32.xxx.xxx resources provided through ppp0.
@mrbaseman
Copy link
Collaborator

This is all inside of the Windows Subsystem for Linux. I could image that outside of this virtual environment something is blocked by the surrounding windows system. I doubt that it's the windows firewall (since establishing the tunnel looks fine), but maybe it's something on the device driver level.

@Kenya-West
Copy link
Author

@mrbaseman thanks for responding, and reminding me that I posted this issue.

Maybe, in a deep level of things, you are right. But currently it is fixed by making two steps:

  1. Disable secure DNS (aka DoH and DoT) in browser settings;
  2. Make sure to set set-dns parameter to 1 in config or command param;
    2.1. Additionally, make sure the DNS server is set in /etc/resolv.conf by listing file contents in cat. If there is not and DNS record should be, then add it by yourself: 
    sudo sed -i '1s/^/nameserver 10.1.1.1\n/' /etc/resolv.conf
    - where 10.1.1.1 IP address of DNS server.

@mrbaseman
Copy link
Collaborator

Ah, now it looks like a DNS configuration issue (from your initial problem description I got a different impression).
I believe the fact that you have to disable secure DNS in browser settings is just because the dns server which you get assigned by the VPN doesn't support it.

The manipulation of /etc/resolv.conf is quite complex and depends on which helpers are installed on your system (see the many issues about this topic). But, looking at the initial config, that you have posted above set-dns = 0 would have instructed openfortivpn not to manipulate DNS configuration. So, setting this parameter to 1 is probably a first move in the right direction. If that still doesn't work reliably, one would have to dive deeper.

In your first post, however, you wrote that even a connection on the IP basis was not possible (with ping and traceroute). On the other hand, is it expected that these hosts are pingable? This depends on the firewall settings on the Fortigate you connect to. If only tcp connections are accepted from the ssl-vpn interface, the ping check is expected to fail. Given the large number of host routes I would suspect that the rules are quite restrictive, and probably icmp traffic is not generally permitted.

@Kenya-West
Copy link
Author

So, setting this parameter to 1 is probably a first move in the right direction

Yes but it sometimes adds DNS server, sometimes not - it depends. In my laptop, set-dns = 1 does the job and populates resolv.conf with the records, while on PC I need to double-check resolv.conf because there are still no DNS records in the file after successful connection. Both have same Windows 11, same WSL distro. The only difference that laptop does not have Docker Desktop installed (in Windows), and the PC does. Docker Desktop only adds additional ip interface:

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

- it is the only difference in ip route show command.

On the other hand, is it expected that these hosts are pingable?

The hosts are pingable.

In your first post, however, you wrote that even a connection on the IP basis was not possible (with ping and traceroute).

Yes, until I write (by set-dns = 1 and manual re-checking) needed DNS records in resolv.conf.

So, in conclusion, I can provide an answer for a random visitor:

  1. Disable secure DNS in browser;
  2. set-dns = 1 in config or command line parameter for openfortivpn;
  3. Check /etc/resolv.conf to see if there are DNS records actually applied. If not, add them yourself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mrbaseman @Kenya-West