[GH-ISSUE #3223] [macOS][VLESS] Split tunnel exclusion for connected LAN subnet routes via router and breaks LAN access #1493

New issue

Open

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

bsakaguchi commented

2026-10-13 20:43:48 +00:00

Owner

Originally created by @renosaza on GitHub (Sep 27, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3223

Summary

On macOS, AmneziaVPN site-based split tunneling in “Addresses from the list should not be accessed via VPN” mode breaks access to a directly connected LAN subnet when that subnet is added to the exclusion list. The client installs the subnet route via the LAN router instead of on-link via Wi-Fi.

Environment

macOS 27.0 (26A428), Wi-Fi en0
AmneziaVPN 5.0.3.0 and 5.0.2.1 macOS .pkg builds (both reproduced)
Amnezia Premium, VLESS/XRay connection
LAN: 192.168.31.0/24; Mac: 192.168.31.105; router: 192.168.31.1
Site-based split tunneling enabled, “Addresses from the list should not be accessed via VPN”, with 192.168.31.0/24 in the list

Reproduction

Connect Wi-Fi on 192.168.31.0/24 and confirm a LAN host such as 192.168.31.47 is reachable directly.
Add 192.168.31.0/24 to site-based split tunneling exclusions and connect VLESS.
Run netstat -rn -f inet, route -n get 192.168.31.47, and ping 192.168.31.47.

Actual

The client creates this route:

192.168.31/24  192.168.31.1  UGSc  en0

The LAN host does not answer. An Ethernet capture on en0 shows ICMP packets for 192.168.31.47 sent to the router's MAC address, not the LAN host's MAC. The router can return Destination Port Unreachable.

Removing 192.168.31.0/24 from the exclusion list removes the bad gateway route, but traffic for the LAN subnet then follows the VPN /1 route and the host remains unreachable. A temporary direct on-link route for the subnet through en0 immediately restores ping and ARP resolution of the LAN host. All temporary routes were removed after diagnosis.

Expected

The connected 192.168.31.0/24 subnet should remain reachable on-link through en0 while the VPN is connected. If explicitly excluded, the client should not route same-subnet packets through 192.168.31.1.

#2830 reports a different Windows route-capture problem affecting connected LAN subnets.
#2937 / #2973 concern loss of CIDR prefix during input normalization; the full /24 is present in the route here, so this is separate.

Originally created by @renosaza on GitHub (Sep 27, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3223 ## Summary On macOS, AmneziaVPN site-based split tunneling in “Addresses from the list should not be accessed via VPN” mode breaks access to a directly connected LAN subnet when that subnet is added to the exclusion list. The client installs the subnet route via the LAN router instead of on-link via Wi-Fi. ## Environment - macOS 27.0 (26A428), Wi-Fi `en0` - AmneziaVPN 5.0.3.0 and 5.0.2.1 macOS `.pkg` builds (both reproduced) - Amnezia Premium, VLESS/XRay connection - LAN: `192.168.31.0/24`; Mac: `192.168.31.105`; router: `192.168.31.1` - Site-based split tunneling enabled, “Addresses from the list should not be accessed via VPN”, with `192.168.31.0/24` in the list ## Reproduction 1. Connect Wi-Fi on `192.168.31.0/24` and confirm a LAN host such as `192.168.31.47` is reachable directly. 2. Add `192.168.31.0/24` to site-based split tunneling exclusions and connect VLESS. 3. Run `netstat -rn -f inet`, `route -n get 192.168.31.47`, and `ping 192.168.31.47`. ## Actual The client creates this route: ```text 192.168.31/24 192.168.31.1 UGSc en0 ``` The LAN host does not answer. An Ethernet capture on `en0` shows ICMP packets for `192.168.31.47` sent to the router's MAC address, not the LAN host's MAC. The router can return `Destination Port Unreachable`. Removing `192.168.31.0/24` from the exclusion list removes the bad gateway route, but traffic for the LAN subnet then follows the VPN `/1` route and the host remains unreachable. A temporary direct on-link route for the subnet through `en0` immediately restores ping and ARP resolution of the LAN host. All temporary routes were removed after diagnosis. ## Expected The connected `192.168.31.0/24` subnet should remain reachable on-link through `en0` while the VPN is connected. If explicitly excluded, the client should not route same-subnet packets through `192.168.31.1`. ## Related reports - #2830 reports a different Windows route-capture problem affecting connected LAN subnets. - #2937 / #2973 concern loss of CIDR prefix during input normalization; the full `/24` is present in the route here, so this is separate.

bsakaguchi referenced this issue

2026-10-14 21:01:42 +00:00

[PR #1493] [CLOSED] Add network status check for AWG/WG protocol #2389