Preflight checks
Describe the bug
With WireGuard connected and split tunneling set to Inclusive mode, IPv6 works for applications included in the tunnel, but applications outside the inclusion list cannot use my ISP's native IPv6 connection.
Native IPv4 continues to work outside the tunnel, and native IPv6 works again immediately after disconnecting Windscribe.
Operating system
Windows 11
OS details
Windows 11 24H2 amd64 (build 26100)
App version
2.23.12
Steps to reproduce
- Connect to a dual-stack network and confirm native IPv6 works while Windscribe is disconnected.
- In Windscribe, select WireGuard and set IP Stack Egress to Auto.
- Enable split tunneling and select Inclusive mode.
- Add a browser or any other application to the included applications.
- Connect to a WireGuard location with working IPv6 egress.
- Confirm that the included application can reach an IPv6-only destination.
- Try reaching the same IPv6 destination from a non-included application such as PowerShell.
- Disconnect Windscribe and repeat the test from PowerShell.
Expected behavior
In Inclusive mode, only applications on the inclusion list should use the VPN. Applications outside the list should retain their normal ISP connectivity, including both native IPv4 and native IPv6.
Actual behavior
Included applications can use IPv6 through the WireGuard tunnel.
Non-included applications can use native IPv4, but native IPv6 is blocked. Disconnecting Windscribe immediately restores native IPv6.
No error message is displayed. IPv6 connections from non-included applications fail with a general network failure or timeout.
Debug log or username
Debug log sent through the Windscribe app on 2026-07-15 around 03:36 CEST. I prefer not to publish my username or raw debug log on GitHub. I can provide my username privately to a Windscribe maintainer or through a support ticket.
Is this a regression?
Not sure
Screenshots
No response
Additional context
Configuration:
- Protocol: WireGuard
- IP Stack Egress: Auto
- Split tunneling: Inclusive mode
- Windscribe firewall: Manual/Off
- ISP connection: Native dual-stack IPv4 and IPv6
The physical Ethernet adapter has a valid global IPv6 address and working IPv6 default gateway.
I also temporarily changed the Windows route metrics so the physical adapter's IPv6 route was preferred over the Windscribe route. Native IPv6 was still blocked for non-included applications, so this does not appear to be caused only by route selection.
A packet capture on the WireGuard server confirmed bidirectional IPv6 traffic from the included application. The VPN server and IPv6 egress are therefore working correctly.
This appears to involve Windscribe's Windows IPv6 WFP/firewall rules blocking off-tunnel IPv6 globally while connected, including traffic from applications that are not part of an Inclusive split tunnel.
Preflight checks
Describe the bug
With WireGuard connected and split tunneling set to Inclusive mode, IPv6 works for applications included in the tunnel, but applications outside the inclusion list cannot use my ISP's native IPv6 connection.
Native IPv4 continues to work outside the tunnel, and native IPv6 works again immediately after disconnecting Windscribe.
Operating system
Windows 11
OS details
Windows 11 24H2 amd64 (build 26100)
App version
2.23.12
Steps to reproduce
Expected behavior
In Inclusive mode, only applications on the inclusion list should use the VPN. Applications outside the list should retain their normal ISP connectivity, including both native IPv4 and native IPv6.
Actual behavior
Included applications can use IPv6 through the WireGuard tunnel.
Non-included applications can use native IPv4, but native IPv6 is blocked. Disconnecting Windscribe immediately restores native IPv6.
No error message is displayed. IPv6 connections from non-included applications fail with a general network failure or timeout.
Debug log or username
Debug log sent through the Windscribe app on 2026-07-15 around 03:36 CEST. I prefer not to publish my username or raw debug log on GitHub. I can provide my username privately to a Windscribe maintainer or through a support ticket.
Is this a regression?
Not sure
Screenshots
No response
Additional context
Configuration:
The physical Ethernet adapter has a valid global IPv6 address and working IPv6 default gateway.
I also temporarily changed the Windows route metrics so the physical adapter's IPv6 route was preferred over the Windscribe route. Native IPv6 was still blocked for non-included applications, so this does not appear to be caused only by route selection.
A packet capture on the WireGuard server confirmed bidirectional IPv6 traffic from the included application. The VPN server and IPv6 egress are therefore working correctly.
This appears to involve Windscribe's Windows IPv6 WFP/firewall rules blocking off-tunnel IPv6 globally while connected, including traffic from applications that are not part of an Inclusive split tunnel.