[Bug] Windows Desktop & WinBoat Guest API crashes on Windows VPN connection

[vb2007]

What version of WinBoat are you running?

WinBoat Beta v0.8.7 Prod

Your Environment

• Linux Distro used: Arch (kernel version: 6.17.5-arch1-1)
• Desktop Environment used: Hyprland 0.51.1
• FreeRDP type and version used: freerdp-2:3.17.2-4 installed through Pacman
• Windows VM Type: Windows 10 LTSC 2021

To avoid lag in native Wayland ( #308 ), I've modified the desktop entry, but this is most likely unrelated:

[Desktop Entry]
Name=WinBoat
Exec=env ELECTRON_OZONE_PLATFORM_HINT=x11 winboat %U
...

Steps to Reproduce / Context

1. Download Cisco AnyConnect, or any other software that allows VPN connection through Windows settings
2. Open VPN settings on Windows, add a connection, authenticate (if applicable) and connect

Logs

winboat.log

Expected Behavior

The VM should successfully establish a VPN connection.

Current Behavior

When reaching the "Completing the connection" step, the remote view freezes.
The only way to break it, is forcefully killing the remote view window.
After killing it, the WinBoat Guest API goes offline, and the only way to restore it is stopping the VM from WinBoat.

Possible Solution

You can run & connect with Cisco AnyConnect on your host, if the remote server allows it.
Personally, I wouldn't want my host connected to a work VPN monitoring all my traffic.

Cisco's official download page (requires login)
AUR - Cisco Secure Client - Worked for me on host
AUR - Cisco AnyConnect - deprecated, some older VPN servers might accept connections

Quality Notice

• I have checked the issue tracker and verified that this bug is a unique case.

[Gregregorovich]

WinBoat communicates over the network to interface with the Windows Guest. So if a VPN is blocking access to LAN then this is not surprising.

Configuring the VPN client on Windows to either (1) allow LAN connections, or (2) use split-tunnelling to create an exception for the WinBoat Guest Server, should fix this, I think.

[sherfst]

Yeah. I'm also having that issue. If I attempt to connect to Cisco AnyConnect within the VM it fails and if I use the Linux version to establish a connection Winboat falls in a heap - even when I've allowed LAN access

[Alexander-Weinhart]

So my hypothesis is that the docker install that is used here can't fudge a VPN connection no matter which way you slice it, because of how the ports and private IP addresses are set up. I'm installing Expressvpn on my actual Linux computer to test this. It's on its way to my hard disk right now, let's see if this works. Stay tuned for a part 2.

[sherfst]

Interestingly, I can VPN from within the VM - just not with Cisco. I tried port forwarding for localhost but it all doesn't work while using a native Linux VPN

…

On Thu, 13 Nov 2025, 00:07 Alexander Weinhart, ***@***.***> wrote: *Alexander-Weinhart* left a comment (TibixDev/winboat#452) <#452 (comment)> So my hypothesis is that the docker install that is used here can't fudge a VPN connection no matter which way you slice it, because of how the ports and private IP addresses are set up. I'm installing Expressvpn on my actual Linux computer to test this. It's on its way to my hard disk right now, let's see if this works. Stay tuned for a part 2. — Reply to this email directly, view it on GitHub <#452 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALISTYFZB7SR3C4FMRV7EMT34O4UFAVCNFSM6AAAAACK5ODH6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMRUGI3DKMJZGY> . You are receiving this because you commented.Message ID: ***@***.***>

[vb2007]

I was trying to connect directly from the Windows VPN settings. Maybe the built-in VPN connection handler uses some different protocol(s) or calls Windows NT kernel functions that can kill the remote view alongside with the Docker container?

So far, I've tried the following:

1. Adding a static route inside the VM:

   • I've got the default (original) gateway with the following PowerShell command:
     • Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object NextHop
     • It was 172.30.0.1 in my case, I'm not sure if this varies by VM
   • Then added presistent route for the docker host:
     • route add 172.28.0.1 mask 255.255.255.255 172.30.0.1 -p
   • If someone else faces the same issue and tries this, the base command is:
     • route add <docker-gateway-ip> mask 255.255.255.255 <original-gateway> -p

2. Modifying WinBoat's docker-compose.yml file to:

   • Use bridge mode (network_mode: bridge)
   • Use host mode (network_mode: host)
   • Use a separate network:

networks:
  winboat_isolated:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.28.0.0/16
          gateway: 172.28.0.1

services:
  windows:
    #...
    networks:
      - winboat_isolated

[Alexander-Weinhart]

So my hypothesis is that the docker install that is used here can't fudge a VPN connection no matter which way you slice it, because of how the ports and private IP addresses are set up. I'm installing Expressvpn on my actual Linux computer to test this. It's on its way to my hard disk right now, let's see if this works. Stay tuned for a part 2.

so I tried ExpressVPN on bare linux, the freeRDP session continued, but I simply couldn't access webpages in Edge. To further test it, I restarted the VM, same deal. Is the solution is to run VPN stuff through WinBoat?