I want to share with you a pro tip to make programming on Windows a little easier with the help of the [WSL 2](https://docs.microsoft.com/en-us/windows/wsl/about).

Imagine you are developing an API, web app, website, etc. on your Windows machine under WSL2. For example, in my case, [my own website](/). I use the React framework [Next.js](https://nextjs.org/), and yarn as package manager, so if I want to start the development server to check my site I just do:

```bash
yarn dev
```

With the above command, the development server will start and listen on port `3000`. It will serve the page to every device that can reach it, as it's serving the site on the `0.0.0.0` address by default. 

![Starting the dev server of my website {priority}{859x154}](/images/articles/accessing-network-apps-running-inside-wsl2-from-other-devices-in-your-lan-1e1p/4uzme7peiaxhkbvykuuk.png) 

Then, if I visit `localhost:3000` on my Windows machine, everything works. The server returns my live website. However, what happens when I try to open my live site from my mobile phone? I navigate to `<my_windows_local_ip>:3000` and then

![The site can't be reached {589x684}](/images/articles/accessing-network-apps-running-inside-wsl2-from-other-devices-in-your-lan-1e1p/lppaoyo9copyqc1x1cki.jpg)

## The solution: forwarding ports in WSL 2 NAT

WSL 2 creates a [virtualized Ethernet adapter with its own unique IP address](https://docs.microsoft.com/en-us/windows/wsl/compare-versions#accessing-a-wsl-2-distribution-from-your-local-area-network-lan), so in fact it creates a NAT between your WSL instance and your Windows host computer. So to be able to access applications running in your WSL from within your Local Area Network (LAN), you must port forward the desired ports.

The solution is to add a port proxy in the Windows Firewall, so we open a PowerShell terminal with administrator rights and execute the following command:

```powershell
netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=<the_wsl_ip>
```

You can get the WSL virtual machine IP right from PowerShell, by executing bash:

```powershell
bash.exe -c "ip -4 addr show eth0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'"
```

Or the same from within the WSL instance:

```bash
ip -4 addr show eth0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'
```

After executing the `netsh interface` command in an administrator PowerShell, the server can now be reached without further configuration needed, nor restarting the server.

![Now it works! {590x736}](/images/articles/accessing-network-apps-running-inside-wsl2-from-other-devices-in-your-lan-1e1p/qg9fd6gj3v9xo1hv1nzo.jpg)

## Bonus: a PowerShell script to simplify this task

The IP address of the WSL VM changes every time it reboots (like when you power off your Windows), so if you have already added a port proxy for an IP address, it might not work if you restart your computer.

I have created a PowerShell script to simplify this task when you need it to be done. You could also configure a Windows task to execute this PowerShell script on every reboot, if you also start WSL on boot (because WSL needs to be launched to get its IP address). Or could be a way to executing it from WSL once it starts. I'm not explaining here how to achieve this, as I don't have configured it that way. I don't usually access apps running inside WSL from my LAN, so when I need to do this, I just execute the following script in an administrator PowerShell terminal **(explanation below)**:

```powershell
$remoteport = bash.exe -c "ip -4 addr show eth0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'"
$found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';

if( $found ){
  $remoteport = $matches[0];
} else{
  echo "The Script Exited, the ip address of WSL 2 cannot be found";
  exit;
}

#[Ports]

#All the ports you want to forward separated by coma
$ports=@(80,443,3000,3001,3002,3333,5000,5432,6000,8080,8081,19000,19001);


#[Static ip]
#You can change the addr to your ip config to listen to a specific address
$addr='0.0.0.0';
$ports_a = $ports -join ",";


#Remove Firewall Exception Rules
iex "Remove-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' ";

#adding Exception Rules for inbound and outbound Rules
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Outbound -LocalPort $ports_a -Action Allow -Protocol TCP";
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Inbound -LocalPort $ports_a -Action Allow -Protocol TCP";

for( $i = 0; $i -lt $ports.length; $i++ ){
  $port = $ports[$i];
  iex "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr";
  iex "netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectport=$port connectaddress=$remoteport";
}
```

What this script does is:
- Gets the IP address of the WSL VM.
- Defines the ports you want to proxy/forward. You can therefore edit the `$ports` array as you wish. Here I have written all the ports I could potentially use, so the script will be valid for multiple apps/technologies.
- Adds Windows Firewall rules to allow all inbound/outbound traffic to the WSL. Also removes old rules from previous script executions (with different IP addresses).
- Adds the required port proxies, at the same times that removes old ones from old script executions (with different IP addresses).

If this is the first time that you execute this script, or you have added a new port, you can get a lot of *not found* messages. These are normal warnings that you can safely ignore, as these occur because the script is trying to delete non-existent firewall rules (first time execution) or port proxies (when you add a new port).

I hope this serves you to improve your developer experience in WSL and make you more productive. If you want to continue improving your WSL experience, check [how to run GUI applications on WSL2](/blog/how-to-use-gui-apps-in-wsl2-forwarding-x-server-cdj).

If you have ever tried to access an app running inside WSL and weren't able to connect, here I show yo how to open ports and forward apps in the WSL NAT.

Accessing network apps running inside WSL2 from other devices in your LAN

I recently had to face with such a problem while developing a REST API for a customer's project at work. I was providing endpoints to populate multiple table views, of different kind of data, with pagination. We use [Nest.js](https://nestjs.com/) and Typescript to develop the API, and we rely on the [auto-generated Swagger](https://docs.nestjs.com/openapi/introduction) documentation to keep the API docs up to date.

So I wanted to use a generic `PaginatedResponseDto` like this:

```typescript
export class PaginatedResponseDto<T> {
  @ApiProperty()
  data: T[]
  @ApiProperty()
  totalCount: number
  @ApiProperty()
  offset: number
  @ApiProperty()
  limit: number
}
```

But Swagger won't be able to extract anything from `T` to generate the correct OpenAPI schema definition. That's because `nestjs/swagger` uses TypeScript reflection capabilities, and unfortunately, TypeScript reflection doesn't work with generics.

However, there is a way to write our own raw OpenAPI schema definitions, and we can use that to achieve what we want. First, we remove the `@ApiProperty` decorator for the `data` attribute from the above DTO, as we will provide its own schema definition later on.

```typescript
export class PaginatedResponseDto<T> {
  data: T[]
  @ApiProperty()
  totalCount: number
  @ApiProperty()
  offset: number
  @ApiProperty()
  limit: number
}
```

Now, we can create a **custom decorator** to use on the endpoints that will return a `PaginatedResponseDto`. In my case, it was named `ApiOkResponsePaginated`:

```typescript
export const ApiOkResponsePaginated = <DataDto extends Type<unknown>>(dataDto: DataDto) =>
  applyDecorators(
    ApiExtraModels(PaginatedResponseDto, dataDto),
    ApiOkResponse({
      schema: {
        allOf: [
          { $ref: getSchemaPath(PaginatedResponseDto) },
          {
            properties: {
              data: {
                type: 'array',
                items: { $ref: getSchemaPath(dataDto) },
              },
            },
          },
        ],
      },
    })
  )
```

A little explanation about what this does.

- The custom decorator receives as the parameter `dataDto` the DTO class that will replace `T` in our generic DTO.
- The `ApiExtraModels` decorator from `nestjs/swagger` indicates swagger to generate and construct the OpenAPI schema for both DTOs, our `PaginatedResponseDto` and whatever DTO we will use to type the `data` attribute.
- `allOf` is for OpenAPI 3 to cover inheritance use-cases.
- We use `getSchemaPath` to retrieve the `PaginatedResponseDto` OpenAPI schema, and then we fine-tune its `data` attribute, indicating that it's of type `array` and that the OpenAPI schema for its items is the one generated for `dataDto`.

And this is how we will use it for, for example, a products list endpoint for an e-commerce:

```typescript
@Controller('products')
export class ProductsController {

  @Get('/')
  @ApiOkResponsePaginated(ProductDto)
  async get(): Promise<PaginatedResponseDto<ProductDto>> {}
}
```

Now, you can check your Swagger auto-generated documentation and see that everything is working as expected. Hurrah!

This is the very basis to make generic DTOs works. The `ApiOkResponsePaginated` decorator can be customized as needed, like for example adding a `description` attribute inside the `data: {}` object to provide a description about the data returned. Whatever `nestjs/swagger` allows you to do, can be done here, so you can make sure your OpenAPI spec is correct and covered.

In this post I show you how to use TypeScript generics inside a Nest.js DTO in a way that allows Swagger to generate the correct OpenAPI schema definition.

How to generate Generics DTOs with nestjs/swagger

If you have already read some of [my WSL related articles](/blog?tags=wsl), chances are that you are using and/or have discovered the potential of WSL 2. However, you might have experimented problems if tried to launch any graphical application within it.

Nowadays, a third-party app is required to run GUI apps, but Microsoft announced on Build 2020 that [adding Linux GUI app native support to WSL is on their roadmap](https://devblogs.microsoft.com/commandline/the-windows-subsystem-for-linux-build-2020-description/#wsl-gui). I currently use *VcXsrv Windows X Server* for that purpose, and that's the tool I will explain on this post. It's an old open-source tool that updates quite frequently. [You can check it on Sourceforge](https://sourceforge.net/projects/vcxsrv/).

## Installing and configuring VcXsrv
The first step is to download and run the `.exe` [installer from Sourceforge](https://sourceforge.net/projects/vcxsrv/). On the installation wizard, be sure to check the *Disable access control* option. This will save us time, avoiding some *permission denied* errors.

![Be sure to disable access control {priority}{508x400}](/images/articles/how-to-use-gui-apps-in-wsl2-forwarding-x-server-cdj/c9fsd1f4vlhkcqroffl4.png)

To be sure that this option is always checked, save the configuration to later launch VcXsrv using that config file.

![How to save VcXsrv configuration {501x396}](/images/articles/how-to-use-gui-apps-in-wsl2-forwarding-x-server-cdj/x370kq1k7asyda7zq8op.png)

## Setting permissions in Windows Firewall
Once VcXsrv is installed, we need to set the proper permissions on our firewall. Here, I assume you use the default Windows Firewall, but if you use a custom firewall (like a firewall provided by an antivirus), you may need to configure it manually.

When executing VcXsrv for the first time, a Windows Firewall pop-up should appear. Just be sure to give it permissions on both private and public networks.

![Setting permissions in Windows Firewall {658x476}](/images/articles/how-to-use-gui-apps-in-wsl2-forwarding-x-server-cdj/fumy6n0d8f3c1vowd3rg.png)

If the pop-up doesn't appear, or if you gave it the wrong permissions by mistake, you can just change the permissions manually. To do so, open `Windows Security` app and go to `Firewall & network protection -> Allow an app through firewall` and ensure *VcXsrv windows x server* has both permissions.

## Setting the `DISPLAY` env var
The last step is to set the `DISPLAY` environment variable on our WSL 2 Linux instance. We need to configure the Windows host's IP address as `DISPLAY` (where the VcXsrv X server is running). Also, because WSL 2 network changes on every restart, so the Windows host's IP does too, it's needed to dynamically set this value on WSL2 launch.

We can use one of the following statements to dynamically set the `DISPLAY` env var to the correct value.

```bash
export DISPLAY="`grep nameserver /etc/resolv.conf | sed 's/nameserver //'`:0"
export DISPLAY="`sed -n 's/nameserver //p' /etc/resolv.conf`:0"
export DISPLAY=$(ip route|awk '/^default/{print $3}'):0.0
```

If you run one of the above commands on your Linux terminal, then, you should see and local IP address when reading the var value. Just use whatever of the above that works correctly on your machine.

```bash
export DISPLAY=....
echo $DISPLAY # Example working output: 192.168.128.1:0.0
```

Lastly, to ensure the DISPLAY env var is updated on every restart, we should add the chosen `export` statement to our `~/.bashrc` file (if you are using bash as your command interpreter) or in `~/.zshrc` (if using zsh instead).

## Testing it out

Let's test it! First, ensure the VcXsrv is running. You can check it by looking at the icons on your task bar. You should be able to see the VcXsrv icon if the server is up and running.

![VcXsrv running on the task bar {212x72}](/images/articles/how-to-use-gui-apps-in-wsl2-forwarding-x-server-cdj/b44988fz25hfs0j6ktq6.png)

If you can't see any icon, just start the server by double-clicking on the config file you saved when installing. It will launch VcXsrv server with the configuration on that file. You can open the file with a text editor, if you want to check the configuration inside.

If you have followed all the above steps, you should be able to execute GUI apps within WSL2 already. Let's try with the `x11-apps`, some very low resources and low dependencies apps made for testing X server configurations.

```bash
sudo apt install x11-apps
xeyes
xcalc
```

![GUI apps running on WSL2 Ubuntu {880x369}](/images/articles/how-to-use-gui-apps-in-wsl2-forwarding-x-server-cdj/g9xjdjgs2v7mjd4ljzjh.png)

After executing the above commands, you should see two eyes following your mouse. Congratulations! You have successfully configured your WSL2 instance to run GUI apps.

Now what's next? If you want to know how to [write code inside WSL with VS Code and run containerized apps using Docker](/blog/how-to-be-a-productive-programmer-in-windows-with-wsl2-5185), I wrote about it too.

## Troubleshooting

I particularly had an issue trying to use the default `0.0` display as my X server. Indeed, trying to use `0.0` will make the X server to crash on my Windows machine. It took me a few hours to realize, after searching on Google for a while and trying multiple different fixing options.

If you have the same problem, may you can fix it by using the `1.0` display instead. This is how I set the `DISPLAY` value.

```bash
export DISPLAY=$(ip route | awk '/default/ { print $3 }'):1.0
```

And this is my VcXsrv `config.xlaunch` config file.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<XLaunch WindowMode="MultiWindow" ClientMode="NoClient" LocalClient="False" Display="1" LocalProgram="xcalc" RemoteProgram="xterm" RemotePassword="" PrivateKey="" RemoteHost="" RemoteUser="" XDMCPHost="" XDMCPBroadcast="False" XDMCPIndirect="False" Clipboard="True" ClipboardPrimary="True" ExtraParams="" Wgl="True" DisableAC="True" XDMCPTerminate="False"/>
```

I will teach how to run Linux GUI (Graphical User Interface) apps from within the WSL2 using an open source third party tool called VcXsrv Windows X Server.

I'm Aitor 👋

Popular Articles

Accessing network apps running inside WSL2 from other devices in your LAN

How to generate Generics DTOs with nestjs/swagger

How to use GUI apps in WSL2 (forwarding X server)