Using the Forti client through the Windows Subsystem for Linux

23:24
11.09.2024
Kenya-West
139

TL;DR The article discusses accessing corporate resources through a Forti connection from the Windows Subsystem for Linux.

Disclaimers

General Disclaimer • About the Author • Disclaimer of Liability • On the Use of Neural Networks

Abstract

There was a situation where sometimes (almost always) you have to keep two proxies/VPNs for free access to the Internet and slightly less free access to the company's intranet. Suppose both connections work by creating TUN adapters in Windows, which 100% guarantees conflicts in network routing, which you are unlikely to want to resolve even if you are a network engineer three times over - the adapters are virtual, created for every sneeze, and writing routes between them will drive you crazy even with the help of the almighty PowerShell.

And you have one device, simply because it's convenient for you. Or several devices, but you want to have corporate access on all of them without losing personal space.

The first VPN can be Nekoray, Hiddify, Amnezia, or other bad and ~~in the near future~~ criminally punishable names, and the second is Forti with their "favorite" client, which works, let's say, with the same enthusiasm as the average worker on a Friday evening, because it is written in Electron with all the ensuing consequences. There can be no question of the joint work of two such different software solutions - when both are turned on at the same time, either one works, or the other, or nothing can reach the Network at all.

Example of FortiClient VPN window content

This article offers a solution to the problem of two Proxy/VPN clients. Fortunately, modern Windows has a "second" OS (in fact, there can be as many as you want) - WSL (to maintain the level of stuffiness, we mean WSL 2). In this case, you can use the second OS on Linux to access and work in the corporate network. We will work specifically with Ubuntu 24.04. Because we can!

Instructions

Requirements

All that part of the workflow that depends on corporate access can be easily migrated to the Linux ecosystem without residue (for example, you only use a browser and cross-platform frontend development utilities (VS Code, Node, npm));
Knowledge of working in Windows 11+ at an above-average level (everyone defines it for themselves, mine is 25 centimeters - believe it or not);
Knowledge of basic work with the terminal, GNU/Linux in general and Ubuntu 24.04+ in particular;
Windows 11 with developer mode enabled;
WSL enabled;
Read also:
- Raspberry CM5 is an incredible New Year's gift
- If you already have WSL installed and enabled, make sure you are working on WSL version 2.
Ubuntu installed and configured (user added, Internet access available);
Your infrastructure is mostly on-premise/self-hosted;
You connect via FortiClient VPN over SSL-VPN, not IPsec VPN;
You know the connection details to the Forti server (domain, port, your login and password) and you have the FortiToken application installed to generate OTP codes for logging into the corporate VPN;
You know the address of the DNS server that links corporate domains and IP addresses in your local network. Ask your local sysadmin or devops.

Sequence of actions aka algorithm

Go to the console with the Ubuntu distribution: in Windows, press Win + R → type ubuntu. That's it, from now on we work there;
Install your favorite browser: Microsoft Edge or Google Chrome;
Install the openfortivpn package: sudo apt install -y openfortivpn;

Create a config with this command:

 cat > ~/.openfortivpnconfig<
 port = 
 username = 
 password = 
 set-dns = 1
 use-resolvconf = 1
 pppd-use-peerdns = 0
 pppd-log=/var/log/openfortivpn.log
 # This X509 certificate entry allows you to skip the unsecured connection warning. I don't know why, but it works!
 trusted-cert = fa0ce72653d7946106170d147e20113a97b02f7200bf11e8e5e5029efb339720
 EOF

Let's start!

5.1. By the way, prepare the FortiToken mobile app, you will need it right now.
```
sudo openfortivpn -c ~/.openfortivpnconfig -o 
```

If everything is fine, the output should be like this:

Check

This step can ideally be skipped, but I almost guarantee you - it won't work on the first run. Therefore, I will describe a couple of checks.

ℹ️ Now you need to remember the DNS server address that is sent after connecting to Forti. For readability, it is assumed here as 10.32.2.1

Open another panel or tab in Windows Terminal/console window with a new connection to the same Ubuntu: Win + R → type ubuntu;
Check that everything should work. Ping, for example, your task manager domain:
```
ping -c 1 
```
If the line with the domain has an IP address starting with a gray IP range, like "10.32", "172.0", "192.168", then everything is fine. If not, keep reading.
Check the routes:
```
ip route show | grep "10.32.2.1" # check the DNS server address in the routing table entries
```
It should output at least one line, something like: 10.32.2.1/31 dev ppp0 scope link. This means that everything is fine, traffic to IP addresses 10.XXX.XXX.XXX will go through the newly created network interface ppp0.

Now check resolv.conf:
```
cat /etc/resolv.conf | grep "10.32.2.1"
```
If the output contains the line nameserver 10.32.2.1, then everything is fine. If not, add it here:
```
sudo sed -i '1s/^/nameserver 10.32.2.1\n/' /etc/resolv.conf
```
ℹ️ Attention! WSL will overwrite the contents of this file after a while. To prevent it from overwriting the file, you need to follow the instructions from it and fix wsl.conf, see the instructions: cat /etc/resolv.conf.

Launch

Launch the browser! With the command microsoft-edge or google-chrome, whichever you prefer! The browser will launch in the Linux environment. Use it.

ℹ️ If your corporate intranet resources are still not accessible, you need to enable+disable Secure DNS and any proxy/VPN settings/extensions in the browser settings.
Transfer your entire development toolchain, which directly depends on access to the corporate network, to WSL, specifically to Ubuntu. If your toolchain consists only of VS Code, simply create/clone the project folder and write code ., it will download the server and launch the Windows VS Code with a connection to WSL via SSH. Voila!

Screenshots for distraction:

A typical running terminal looks something like this

Pluses and minuses

Advantages of this approach:

+ All-in-one: you can use both personal and corporate VPN;
+ WSL uses Windows routes, so if you have a client on Windows that has set up its own TUN adapter, Linux will also use this traffic. In this case, it is convenient to have access to both blocked and corporate sites at the same time;
+ In theory, it should work with Dev containers in VS Code both in the cloud and locally, so you can access the corporate network for debugging even from a tablet on github.dev;
+ It's better than having an RDP session to a specially equipped device for work (well, this is subjective, but I'm tired of these 10 fps. And yes, I know that you can increase the frame rate, but it's not the same, it's a surrogate);
+ You can use only personal devices and not be responsible for corporate property. Less responsibility - less time from the prosecutor!

Cons:

- Increased power consumption of the device + part of the computing resources will start to be consumed by WSL. Not much, but if a browser running through Linux gets caught on a particularly resource-intensive tab... The window will just freeze and you won't be able to kill it easily through Task Manager and top (because you won't guess right the first time with one of the hundred identical processes) without shutting down the entire WSL (Powershell: wsl --shutdown);
- For perfectionists and tech enthusiasts: yes, this is WSL 2. Yes, it is essentially a Hyper-V virtual machine. Yes, it is not much different from it. Yes, the browser and windows from Linux are rendered through RDP via X-Server. Yes, I have come to terms with this, become a victim of LDPR propaganda from M$ and receive fabulous sums from them for this article on tekkix. Yes, I know that I automatically get banned from attending any GNU conference for 5 years without the right to compile the kernel. Yes, it is convenient for me and I enjoy the organized development process. Yes, I thank Microsoft for inventing WSL;
- Abstractions and the very essence of separating work and personal life are mixed. The solution is simple: give up personal life. And it was easy for me.

Notes

As a result, you essentially get two machines: Windows for personal needs, where your personal Proxy/VPN client works, and Linux, where everything is set up for work. Linux, located inside Windows, will also go through your personal VPN, keep that in mind.

As you may have noticed in the OpenFortiVPN config, you can do without directly specifying the DNS server in /etc/resolv.conf, and it works - but only if Docker with WSL integration is not installed in Windows. It adds its own entry to the routing table:

ip route
default via 172.28.64.1 dev eth0 proto kernel
172.28.64.0/20 dev eth0 proto kernel scope link src 172.28.79.89 # This one?

- and everything breaks for some reason. I'm not a network specialist, so I don't want to figure out why.

To launch the browser without output to stdout, you can use the nohup utility: nohup microsoft-edge &. This will allow you to free up the terminal panel/window for more important tasks.

Do not keep the Linux browser running for more than two days in a row! For some reason, it almost certainly hangs over time.

By the way, most likely, all this will work on Windows 10 as well... although I haven't seen it live for a couple of years.

Of course, there are other ways to organize access to the corporate intranet, but this one seemed to me the most elegant, as it visually creates the most "nativeness". And if you don't notice unnecessary abstractions in the form of an RDP connection to a work computer or a specially prepared virtual machine, then it is psychologically easier to work. IMHO.

Do you want to go further and get rid of the proprietary FortiToken Mobile as well? Then you should read the manual (root is needed on the phone).

Conclusions

The instruction will be useful in any country where the rights and freedoms of citizens on the Internet are restricted, which is why it is necessary to tunnel traffic not only for access to the company's network, but also for oneself. The article is suitable for people with the needs and situations described in the annotation, and only for them. These can be people of different IT orientations: from managers and analysts to developers and leads without the arch-warden complex. The instruction is described, a few troubleshooting paths (diagnostics of malfunctions), the pros and cons of this approach, as well as notes. And it's still good that WSL exists!