amnezia-vpn/amnezia-client

Fork 0

mirror of https://github.com/amnezia-vpn/amnezia-client.git synced 2026-10-13 21:33:09 +00:00

[GH-ISSUE #3279] [Windows][5.0.3.0] Excluding Weixin.exe via app split tunneling breaks voice/video calls, while text messaging works #1522

New issue

Open

opened 2026-10-13 20:44:13 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-13 20:44:13 +00:00

Owner

Originally created by @start-point on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3279

Describe the bug

On Windows 10, excluding Weixin.exe (WeChat for Windows) from the VPN using application-based split tunneling causes WeChat video calls to fail.

The VPN connection itself works correctly, and WeChat video calls succeed when application-based split tunneling is disabled or when Weixin.exe is not excluded.

After performing six controlled tests (A–F), I found that adding Weixin.exe to the application exclusion list consistently triggers the problem, while excluding WeChatAppEx.exe alone does not.

WeChat TCP connections appear to use the physical Ethernet interface when the main executable is excluded. However, the video call fails, and the observed UDP socket bindings differ from those seen during successful calls.

In some cases, the problem temporarily persists after disconnecting the VPN and fully restarting WeChat.

Important clarification: WeChat text messaging works normally in all tested configurations (A–F). I can send and receive text messages without any issues, even when Weixin.exe is excluded from the VPN. Only voice and video calls fail to connect.

This suggests that the issue specifically affects real-time calling functionality rather than general network connectivity. It may be related to UDP traffic handling, socket binding, or network interface selection, although the exact cause has not yet been confirmed.

To Reproduce

On Windows 10, install AmneziaVPN 5.0.3.0 and connect to a self-hosted VPN server.
Disable site-based split tunneling and keep KillSwitch disabled.
Enable application-based split tunneling.
Select the mode where applications in the list should bypass the VPN.
Add Weixin.exe to the exclusion list.
Connect to the VPN.
Completely restart WeChat.
Start a new WeChat voice or video call.

Actual result: WeChat text messages can still be sent and received normally, but voice and video calls fail to connect or show a call-disconnected message.

Expected result: WeChat should use the physical network connection for all required traffic, including video calls, while the VPN remains active for other applications.

Controlled test results

Test	VPN	App split tunneling	Excluded WeChat executables	Voice/video calls
A	Off	N/A	N/A	Works
B	On	Off	None	Works
C	On	On	`Weixin.exe` + `WeChatAppEx.exe`	Fails
D	On	On	Neither executable	Works
E	On	On	Only `Weixin.exe`	Fails
F	On	On	Only `WeChatAppEx.exe`	Works

Text messaging works normally in all six scenarios.

This strongly suggests that the issue is specifically triggered by excluding the main Weixin.exe process, rather than simply enabling the split-tunneling driver.

Another observation:

After test C failed, disconnecting the VPN and fully restarting WeChat did not immediately restore video calling.
Switching back to test B restored video calling.
Subsequently, test A also worked again.

Network observations

Physical Ethernet IPv4 address:

192.168.1.100

VPN/TUN interface observed:

tun2 — 10.33.0.2

Using PowerShell Get-NetTCPConnection, WeChat TCP connections showed different local addresses depending on the configuration:

With VPN enabled and app split tunneling disabled (B), observed TCP local address: 10.33.0.2.
With app split tunneling enabled and WeChat excluded (C), observed TCP local address: 192.168.1.100.

This suggests that at least some TCP connections are being directed toward the physical interface when WeChat is excluded.

However, the UDP socket bindings also differ.

During successful video calls (A/B), Get-NetUDPEndpoint showed entries such as:

LocalAddress             LocalPort
::                       50241
::ffff:192.168.1.100     50248
::ffff:192.168.1.100     41446
::ffff:192.168.1.100     35673

During a failed video call with both executables excluded (C), only the following UDP endpoint was observed for the inspected process:

LocalAddress                         LocalPort
fe80::e803:305a:d78c:e7f9%15        62617

These observations do not prove that UDP packets are being dropped. It is also possible that WeChat fails to initialize the required IPv4 media sockets when the main process is excluded.

A packet capture may be required to determine the exact cause.

Log files

The AmneziaVPN Windows service log contains repeated entries similar to:

AmneziaVPN WindowsSplitTunnel : Starting SplitTunnel
AmneziaVPN WindowsSplitTunnel : Driver is ready
AmneziaVPN WindowsSplitTunnel : Getting adapter info for: tun2
AmneziaVPN WindowsSplitTunnel : Ipv6 Conversation error 10022
AmneziaVPN WindowsSplitTunnel : Getting adapter info for: 以太网
AmneziaVPN WindowsSplitTunnel : Ipv6 Conversation error 10022
AmneziaVPN WindowsSplitTunnel : New Network Config Applied
AmneziaVPN WindowsSplitTunnel : New Configuration applied: STATE_RUNNING

The service also reports:

AmneziaVPN WindowsSplitTunnel : Stopping Split tunnel successfull

No explicit Failed to set Config or Failed to set Network Config error was found in the filtered output.

The IPv6 conversion error also appears during configurations where video calling works, so I cannot confirm that it is directly responsible.

Desktop

OS: Windows 10 22H2
AmneziaVPN client: 5.0.3.0
WeChat for Windows version: [4.1.15.13]
Network: Ethernet, IPv4 192.168.1.100
Application: WeChat for Windows (Weixin.exe)
Main executable: D:\SoftWare\weixin\Weixin.exe
Helper executable: WeChatAppEx.exe
KillSwitch: Disabled
Site-based split tunneling: Disabled
App split tunneling: Enabled for tests C–F
Split tunneling mode: Excluded applications should NOT use the VPN

Server

Self-hosted VPN on a Linux VPS
AmneziaWG 3.1 is installed server-side
The active protocol/profile in the Windows client should be verified separately, because the observed Windows TUN interface is named tun2 with address 10.33.0.2.

#2586 — Windows app-based split tunneling does not work correctly
#2932 — Application split tunneling ignores exclusions / routing issues
#3263 — App split tunneling problems in client 5.0.3.0
#1148 — UDP connection problems with split tunneling

Additional context

The important distinction is between tests E and F:

E: Exclude only Weixin.exe → video calls fail.

F: Exclude only WeChatAppEx.exe → video calls work.

This issue is reproducible without KillSwitch enabled. The failure depends on excluding the main WeChat executable, not merely on enabling application-based split tunneling.

Could the maintainers investigate how the Windows split-tunneling driver handles UDP sockets, address binding, and route selection for an excluded main process?

In particular, it would be helpful to determine why video calls fail only when Weixin.exe is excluded, even though ordinary TCP connections can still be established.

I can provide additional sanitized logs, routing information, or Wireshark captures if needed.

Thank you for maintaining AmneziaVPN.

Originally created by @start-point on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3279 ## Describe the bug On Windows 10, excluding `Weixin.exe` (WeChat for Windows) from the VPN using application-based split tunneling causes WeChat video calls to fail. The VPN connection itself works correctly, and WeChat video calls succeed when application-based split tunneling is disabled or when `Weixin.exe` is not excluded. After performing six controlled tests (A–F), I found that **adding `Weixin.exe` to the application exclusion list consistently triggers the problem**, while excluding `WeChatAppEx.exe` alone does not. WeChat TCP connections appear to use the physical Ethernet interface when the main executable is excluded. However, the video call fails, and the observed UDP socket bindings differ from those seen during successful calls. In some cases, the problem temporarily persists after disconnecting the VPN and fully restarting WeChat. Important clarification: WeChat text messaging works normally in all tested configurations (A–F). I can send and receive text messages without any issues, even when Weixin.exe is excluded from the VPN. Only voice and video calls fail to connect. This suggests that the issue specifically affects real-time calling functionality rather than general network connectivity. It may be related to UDP traffic handling, socket binding, or network interface selection, although the exact cause has not yet been confirmed. ## To Reproduce 1. On Windows 10, install AmneziaVPN 5.0.3.0 and connect to a self-hosted VPN server. 2. Disable site-based split tunneling and keep KillSwitch disabled. 3. Enable application-based split tunneling. 4. Select the mode where applications in the list should bypass the VPN. 5. Add `Weixin.exe` to the exclusion list. 6. Connect to the VPN. 7. Completely restart WeChat. 8. Start a new WeChat voice or video call. **Actual result:** WeChat text messages can still be sent and received normally, but voice and video calls fail to connect or show a call-disconnected message. **Expected result:** WeChat should use the physical network connection for all required traffic, including video calls, while the VPN remains active for other applications. ## Controlled test results | Test | VPN | App split tunneling | Excluded WeChat executables | Voice/video calls| |---|---|---|---|---| | A | Off | N/A | N/A | Works | | B | On | Off | None | Works | | C | On | On | `Weixin.exe` + `WeChatAppEx.exe` | Fails | | D | On | On | Neither executable | Works | | E | On | On | Only `Weixin.exe` | Fails | | F | On | On | Only `WeChatAppEx.exe` | Works | Text messaging works normally in all six scenarios. This strongly suggests that the issue is specifically triggered by excluding the main `Weixin.exe` process, rather than simply enabling the split-tunneling driver. Another observation: - After test C failed, disconnecting the VPN and fully restarting WeChat did not immediately restore video calling. - Switching back to test B restored video calling. - Subsequently, test A also worked again. ## Network observations Physical Ethernet IPv4 address: `192.168.1.100` VPN/TUN interface observed: `tun2` — `10.33.0.2` Using PowerShell `Get-NetTCPConnection`, WeChat TCP connections showed different local addresses depending on the configuration: - With VPN enabled and app split tunneling disabled (B), observed TCP local address: `10.33.0.2`. - With app split tunneling enabled and WeChat excluded (C), observed TCP local address: `192.168.1.100`. This suggests that at least some TCP connections are being directed toward the physical interface when WeChat is excluded. However, the UDP socket bindings also differ. During successful video calls (A/B), `Get-NetUDPEndpoint` showed entries such as: ```text LocalAddress LocalPort :: 50241 ::ffff:192.168.1.100 50248 ::ffff:192.168.1.100 41446 ::ffff:192.168.1.100 35673 ``` During a failed video call with both executables excluded (C), only the following UDP endpoint was observed for the inspected process: ```text LocalAddress LocalPort fe80::e803:305a:d78c:e7f9%15 62617 ``` These observations do not prove that UDP packets are being dropped. It is also possible that WeChat fails to initialize the required IPv4 media sockets when the main process is excluded. A packet capture may be required to determine the exact cause. ## Log files The AmneziaVPN Windows service log contains repeated entries similar to: ```text AmneziaVPN WindowsSplitTunnel : Starting SplitTunnel AmneziaVPN WindowsSplitTunnel : Driver is ready AmneziaVPN WindowsSplitTunnel : Getting adapter info for: tun2 AmneziaVPN WindowsSplitTunnel : Ipv6 Conversation error 10022 AmneziaVPN WindowsSplitTunnel : Getting adapter info for: 以太网 AmneziaVPN WindowsSplitTunnel : Ipv6 Conversation error 10022 AmneziaVPN WindowsSplitTunnel : New Network Config Applied AmneziaVPN WindowsSplitTunnel : New Configuration applied: STATE_RUNNING ``` The service also reports: ```text AmneziaVPN WindowsSplitTunnel : Stopping Split tunnel successfull ``` No explicit `Failed to set Config` or `Failed to set Network Config` error was found in the filtered output. The IPv6 conversion error also appears during configurations where video calling works, so I cannot confirm that it is directly responsible. ## Desktop - OS: Windows 10 22H2 - AmneziaVPN client: 5.0.3.0 - WeChat for Windows version: [4.1.15.13] - Network: Ethernet, IPv4 `192.168.1.100` - Application: WeChat for Windows (`Weixin.exe`) - Main executable: `D:\SoftWare\weixin\Weixin.exe` - Helper executable: `WeChatAppEx.exe` - KillSwitch: Disabled - Site-based split tunneling: Disabled - App split tunneling: Enabled for tests C–F - Split tunneling mode: Excluded applications should NOT use the VPN ## Server - Self-hosted VPN on a Linux VPS - AmneziaWG 3.1 is installed server-side - The active protocol/profile in the Windows client should be verified separately, because the observed Windows TUN interface is named `tun2` with address `10.33.0.2`. ## Related issues - #2586 — Windows app-based split tunneling does not work correctly - #2932 — Application split tunneling ignores exclusions / routing issues - #3263 — App split tunneling problems in client 5.0.3.0 - #1148 — UDP connection problems with split tunneling ## Additional context The important distinction is between tests E and F: **E: Exclude only `Weixin.exe` → video calls fail.** **F: Exclude only `WeChatAppEx.exe` → video calls work.** This issue is reproducible without KillSwitch enabled. The failure depends on excluding the main WeChat executable, not merely on enabling application-based split tunneling. Could the maintainers investigate how the Windows split-tunneling driver handles UDP sockets, address binding, and route selection for an excluded main process? In particular, it would be helpful to determine why video calls fail only when `Weixin.exe` is excluded, even though ordinary TCP connections can still be established. I can provide additional sanitized logs, routing information, or Wireshark captures if needed. Thank you for maintaining AmneziaVPN.

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

amnezia-vpn/amnezia-client#1522

No description provided.

Rows
Columns