amnezia-vpn/amnezia-client

Fork 0

mirror of https://github.com/amnezia-vpn/amnezia-client.git synced 2026-10-14 21:34:26 +00:00

[GH-ISSUE #3267] macOS: all traffic stops after an iPhone is connected by USB (gateway ARP entry never re-learned while AmneziaVPN-service routes are installed); only a manual disconnect recovers #1513

New issue

Open

opened 2026-10-13 20:44:05 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

Originally created by @apalihin on GitHub (Oct 7, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3267

Describe the bug

With an Xray connection active on Wi-Fi, connecting an iPhone to the Mac with a USB-C cable kills all traffic within seconds. The Wi-Fi link stays up, but the Mac can no longer reach even its own gateway. The connection stays dead until the user manually disconnects and reconnects in the app. Automatic reconnects ("Reconnect triggered. Reconnecting to the server") do not fix it.

Other devices on the same Wi-Fi network keep working during the outage, so the router is fine.

Environment

AmneziaVPN 5.0.3.0 (de93650), standalone build (pf kill switch, tun2socks on utunN)
macOS 26.6.2 (25G83), Apple silicon (Mac17,6)
Uplink: Wi-Fi en0, gateway 192.168.31.1 (DHCP)
Protocol: Xray (amnezia-xray container)
Route mode: VpnAllExceptSites (site split tunneling enabled), app split tunneling disabled
Firewall anchors at connect time: 100.blockAll ON, 110.allowNets ON, 200.allowVPN ON, 300.allowLAN ON, 310.blockDNS ON

To Reproduce

Connect to the Xray server over Wi-Fi.
Connect a trusted iPhone to the Mac with a USB-C cable. macOS brings up the iPhone USB interfaces (en9/en11 in our case, network service "iPhone USB"). They get no DHCP lease and fall back to an IPv4 link-local address (169.254.x.x).
Within about 1–20 seconds, all traffic stops and never recovers on its own.

This was reproduced 3 times in one night: 2026-10-07 21:34, 21:55 and 22:04 UTC. The third occurrence was captured with route -n monitor (details below).

Expected behavior

The VPN keeps working, or at least recovers automatically after the network change, the same way a manual disconnect/connect recovers it.

What happens (captured)

Excerpts from route -n monitor. All times are local (UTC+3). MAC addresses are redacted.

01:04:08 RTM_IFINFO / RTM_NEWADDR  en10, en11 appear (iPhone USB)
01:04:27 RTM_ADD    pid=349 (configd)  169.254.0.0/16 on en11, addr 169.254.8.164   <- IPv4LL on the iPhone interface
01:04:27 RTM_DELETE pid=349 (configd)  169.254.255.255  index 15 (en0)
01:04:27 RTM_DELETE pid=349 (configd)  192.168.31.1    <gw-mac>   en0               <- gateway ARP entry flushed
01:04:27 RTM_DELETE pid=349 (configd)  192.168.31.54   <mac>      en0
01:04:27 RTM_DELETE pid=349 (configd)  192.168.31.158  <mac>      en0
01:04:27 RTM_DELETE pid=349 (configd)  192.168.31.255  ff:ff:...  en0

Up to 01:04:25 the gateway answered ping every 2 s. From 01:04:27 to 01:09:43 (more than 5 minutes):

ping 192.168.31.1: 100% loss.
arp -n 192.168.31.1: 192.168.31.1 (192.168.31.1) -- no entry. The entry never even becomes (incomplete), so the kernel apparently does not try to ARP for the gateway at all.

route -n get 192.168.31.1: still interface: en0. The routing table is unchanged. The 192.168.31/24 connected route on en0 is present, and the service routes are still installed:

0/1                10.33.0.2      UGScg   utun22
default            192.168.31.1   UGScg   en0
0/1                192.168.31.1   UGScIg  en0
<server-ip>        192.168.31.1   UGHS    en0
128.0/1            10.33.0.2      UGSc    utun22
128.0/1            192.168.31.1   UGScI   en0
192.168.31         link#15        UCS     en0
192.168.31.1/32    link#15        UCS     en0

Direct TCP/TLS to the VPN server (bypassing the tunnel) fails, DNS times out, and there are no Xray outbound sockets to the server.
Wi-Fi itself is healthy: associated, RSSI −22…−28 dBm, SNR 40, beacons 49/50 per 5 s, txFail=0 in the airportd LQM stats. Frames are only being sent in tiny amounts.

Recovery happened at the manual disconnect:

01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service)  default(0/1) 192.168.31.1 ifscope
01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service)  128.0.0.0/1  192.168.31.1 ifscope
01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service)  <server-ip>  192.168.31.1
01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service)  100.64.0.1   192.168.31.1
01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service)  8.8.4.4      192.168.31.1
01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service)  141.8.128.0/18 192.168.31.1   (split-tunnel routes ...)
01:09:45 ping 192.168.31.1 OK, gateway ARP entry is back

So the gateway ARP entry comes back about 2 seconds after the service removes its routes that use 192.168.31.1 as the gateway, and not before.

The automatic reconnect did not recover the earlier occurrence. In the app log (UTC), two automatic reconnects ran during that outage and traffic stayed dead after both:

[2026-10-07 21:58:15.048Z] Reconnect triggered. Reconnecting to the server
[2026-10-07 21:58:15.335Z] Connection state: 'Подключено'
[2026-10-07 21:58:32.372Z] Reconnect triggered. Reconnecting to the server

Only the manual disconnect at 21:59:25Z (stop → full route/pf teardown → connect) restored connectivity, at 21:59:27Z.

Possible cause (hypothesis, not verified in code)

The service installs gateway routes via 192.168.31.1: the ifscoped 0/1 and 128.0/1 routes plus host routes for the server, DNS servers and excluded sites. When configd flushes the ARP cache on en0 (which macOS does when an IPv4LL address is configured on another interface), these gateway routes seem to keep a stale reference to the deleted gateway llinfo entry, so the kernel never re-resolves the gateway. Removing the routes (manual disconnect) releases the stale reference. The automatic reconnect path apparently does not reinstall these routes, so it doesn't help.

Possible fixes:

When the network monitor sees a network change, or when the gateway's ARP/llinfo route is deleted, reinstall the gateway routes the same way the manual disconnect/connect does.
Make the automatic reconnect perform the same full route teardown and reinstall as a manual reconnect.

Workarounds

Manually disconnect and reconnect in the app after plugging in the iPhone.
Make the macOS "iPhone USB" network service inactive. This prevents the IPv4LL address and the ARP flush, but also disables USB tethering.

Other observations (minor, possibly separate issues)

The log message has an unformatted placeholder: "Reconnect triggered on Reconnecting during inappropriate state: %2; ignoring slot". It is repeated about 12 times per reconnect.
Every stop logs Failed to stop xray / [xray] failed to stop: core: failed to close all features > ... failed to close all handlers.
Crash on 2026-10-02: SIGSEGV (EXC_BAD_ACCESS) in QObjectPrivate::connectImpl ← XrayProtocol::startTun2Socks() ← XrayProtocol::start() ← VpnConnection::connectToVpn(), during a reconnect. The .ips report is available.

Possibly related (macOS route handling via the LAN gateway, different trigger): #3223.

Full app and service logs, the route -n monitor capture and the crash report are available on request. The server address and identifiers are redacted here.

Originally created by @apalihin on GitHub (Oct 7, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3267 ### Describe the bug With an Xray connection active on Wi-Fi, connecting an iPhone to the Mac with a USB-C cable kills all traffic within seconds. The Wi-Fi link stays up, but the Mac can no longer reach even its own gateway. The connection stays dead until the user manually disconnects and reconnects in the app. Automatic reconnects ("Reconnect triggered. Reconnecting to the server") do **not** fix it. Other devices on the same Wi-Fi network keep working during the outage, so the router is fine. ### Environment - AmneziaVPN 5.0.3.0 (de93650), standalone build (pf kill switch, `tun2socks` on `utunN`) - macOS 26.6.2 (25G83), Apple silicon (Mac17,6) - Uplink: Wi-Fi `en0`, gateway 192.168.31.1 (DHCP) - Protocol: Xray (`amnezia-xray` container) - Route mode: `VpnAllExceptSites` (site split tunneling enabled), app split tunneling disabled - Firewall anchors at connect time: `100.blockAll ON`, `110.allowNets ON`, `200.allowVPN ON`, `300.allowLAN ON`, `310.blockDNS ON` ### To Reproduce 1. Connect to the Xray server over Wi-Fi. 2. Connect a trusted iPhone to the Mac with a USB-C cable. macOS brings up the iPhone USB interfaces (`en9`/`en11` in our case, network service "iPhone USB"). They get no DHCP lease and fall back to an IPv4 link-local address (169.254.x.x). 3. Within about 1–20 seconds, all traffic stops and never recovers on its own. This was reproduced 3 times in one night: 2026-10-07 21:34, 21:55 and 22:04 UTC. The third occurrence was captured with `route -n monitor` (details below). ### Expected behavior The VPN keeps working, or at least recovers automatically after the network change, the same way a manual disconnect/connect recovers it. ### What happens (captured) Excerpts from `route -n monitor`. All times are local (UTC+3). MAC addresses are redacted. ``` 01:04:08 RTM_IFINFO / RTM_NEWADDR en10, en11 appear (iPhone USB) 01:04:27 RTM_ADD pid=349 (configd) 169.254.0.0/16 on en11, addr 169.254.8.164 <- IPv4LL on the iPhone interface 01:04:27 RTM_DELETE pid=349 (configd) 169.254.255.255 index 15 (en0) 01:04:27 RTM_DELETE pid=349 (configd) 192.168.31.1 <gw-mac> en0 <- gateway ARP entry flushed 01:04:27 RTM_DELETE pid=349 (configd) 192.168.31.54 <mac> en0 01:04:27 RTM_DELETE pid=349 (configd) 192.168.31.158 <mac> en0 01:04:27 RTM_DELETE pid=349 (configd) 192.168.31.255 ff:ff:... en0 ``` Up to 01:04:25 the gateway answered ping every 2 s. From 01:04:27 to 01:09:43 (more than 5 minutes): - `ping 192.168.31.1`: 100% loss. - `arp -n 192.168.31.1`: `192.168.31.1 (192.168.31.1) -- no entry`. The entry never even becomes `(incomplete)`, so the kernel apparently does not try to ARP for the gateway at all. - `route -n get 192.168.31.1`: still `interface: en0`. The routing table is unchanged. The `192.168.31/24` connected route on `en0` is present, and the service routes are still installed: ``` 0/1 10.33.0.2 UGScg utun22 default 192.168.31.1 UGScg en0 0/1 192.168.31.1 UGScIg en0 <server-ip> 192.168.31.1 UGHS en0 128.0/1 10.33.0.2 UGSc utun22 128.0/1 192.168.31.1 UGScI en0 192.168.31 link#15 UCS en0 192.168.31.1/32 link#15 UCS en0 ``` - Direct TCP/TLS to the VPN server (bypassing the tunnel) fails, DNS times out, and there are no Xray outbound sockets to the server. - Wi-Fi itself is healthy: associated, RSSI −22…−28 dBm, SNR 40, beacons 49/50 per 5 s, `txFail=0` in the airportd LQM stats. Frames are only being sent in tiny amounts. Recovery happened at the manual disconnect: ``` 01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service) default(0/1) 192.168.31.1 ifscope 01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service) 128.0.0.0/1 192.168.31.1 ifscope 01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service) <server-ip> 192.168.31.1 01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service) 100.64.0.1 192.168.31.1 01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service) 8.8.4.4 192.168.31.1 01:09:43 RTM_DELETE pid=558 (AmneziaVPN-service) 141.8.128.0/18 192.168.31.1 (split-tunnel routes ...) 01:09:45 ping 192.168.31.1 OK, gateway ARP entry is back ``` So the gateway ARP entry comes back about 2 seconds after the service removes its routes that use 192.168.31.1 as the gateway, and not before. The automatic reconnect did not recover the earlier occurrence. In the app log (UTC), two automatic reconnects ran during that outage and traffic stayed dead after both: ``` [2026-10-07 21:58:15.048Z] Reconnect triggered. Reconnecting to the server [2026-10-07 21:58:15.335Z] Connection state: 'Подключено' [2026-10-07 21:58:32.372Z] Reconnect triggered. Reconnecting to the server ``` Only the manual disconnect at 21:59:25Z (stop → full route/pf teardown → connect) restored connectivity, at 21:59:27Z. ### Possible cause (hypothesis, not verified in code) The service installs gateway routes via 192.168.31.1: the ifscoped `0/1` and `128.0/1` routes plus host routes for the server, DNS servers and excluded sites. When configd flushes the ARP cache on `en0` (which macOS does when an IPv4LL address is configured on another interface), these gateway routes seem to keep a stale reference to the deleted gateway llinfo entry, so the kernel never re-resolves the gateway. Removing the routes (manual disconnect) releases the stale reference. The automatic reconnect path apparently does not reinstall these routes, so it doesn't help. Possible fixes: - When the network monitor sees a network change, or when the gateway's ARP/llinfo route is deleted, reinstall the gateway routes the same way the manual disconnect/connect does. - Make the automatic reconnect perform the same full route teardown and reinstall as a manual reconnect. ### Workarounds - Manually disconnect and reconnect in the app after plugging in the iPhone. - Make the macOS "iPhone USB" network service inactive. This prevents the IPv4LL address and the ARP flush, but also disables USB tethering. ### Other observations (minor, possibly separate issues) - The log message has an unformatted placeholder: `"Reconnect triggered on Reconnecting during inappropriate state: %2; ignoring slot"`. It is repeated about 12 times per reconnect. - Every stop logs `Failed to stop xray` / `[xray] failed to stop: core: failed to close all features > ... failed to close all handlers`. - Crash on 2026-10-02: SIGSEGV (`EXC_BAD_ACCESS`) in `QObjectPrivate::connectImpl` ← `XrayProtocol::startTun2Socks()` ← `XrayProtocol::start()` ← `VpnConnection::connectToVpn()`, during a reconnect. The `.ips` report is available. Possibly related (macOS route handling via the LAN gateway, different trigger): #3223. Full app and service logs, the `route -n monitor` capture and the crash report are available on request. The server address and identifiers are redacted here.

bsakaguchi commented

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

Author

Owner

@SpellfulStd commented on GitHub (Oct 8, 2026):

I see what looks like the same trigger on AmneziaWG, but with a different symptom: the tunnel stays up and only the system DNS setting is lost.

Environment

AmneziaVPN 5.0.3 (macOS .pkg)
macOS 27.0.1 (26A434), Apple silicon (Mac14,10)
Uplink: Wi-Fi en0, gateway 192.168.1.1 (DHCP)
Protocol: AmneziaWG (amneziawg-go on utun8), full tunnel (0/1 and 128.0/1 via utun8)
DNS in the profile: AmneziaDNS (172.29.172.254)

To reproduce

Connect over Wi-Fi. scutil --dns shows nameserver[0] : 172.29.172.254.
Plug a device into the Mac with a USB cable. A new interface appears (en8 here), gets no DHCP lease and falls back to IPv4 link-local (169.254.x.x). configd logs several network changed events.
Name resolution stops and does not recover on its own.

Reproduced twice in one night (2026-10-09, about 00:14 and 02:52 local time, UTC+4). The second time was done on purpose and measured.

What I measured during the failure (02:52–02:53)

scutil --dns, resolver #1: nameserver[0] : 192.168.1.1, if_index : 14 (en0). The AmneziaDNS address is gone, replaced by the DHCP-provided router address. State:/Network/Global/DNS shows the same.
System resolver (dscacheutil -q host): no answer.
dig @192.168.1.1: timeout.
dig @172.29.172.254 (asked directly): answers normally.
ping 1.1.1.1 through the tunnel: 0% loss.
The amneziawg-go process and the 0/1 / 128.0/1 routes were unchanged. The client did not reconnect or restore DNS by itself.

So here the tunnel and the DNS server inside it keep working; the only thing broken is that the system resolver now points at the router, and that is unreachable for DNS while the tunnel is up. Separately, with the tunnel up, port 53 to 1.1.1.1 / 8.8.8.8 times out while ICMP to the same addresses passes, which is consistent with the 310.blockDNS anchor mentioned above.

Not measured: I did not check ping/arp for the gateway during the failure, so I cannot say whether the gateway ARP entry was also flushed as in the original report. The dig @192.168.1.1 timeout could be either that or the DNS block.

Recovery

Turning Wi-Fi off and on made the client restart amneziawg-go; after that scutil --dns showed 172.29.172.254 again and everything worked, with the USB device still attached and en8 still active on its link-local address.

Expected

After a network configuration change the client should re-apply its DNS settings (or reconnect), instead of leaving the system on the DHCP DNS that its own kill switch blocks.

@SpellfulStd commented on GitHub (Oct 8, 2026): I see what looks like the same trigger on **AmneziaWG**, but with a different symptom: the tunnel stays up and only the system DNS setting is lost. ### Environment - AmneziaVPN 5.0.3 (macOS .pkg) - macOS 27.0.1 (26A434), Apple silicon (Mac14,10) - Uplink: Wi-Fi `en0`, gateway 192.168.1.1 (DHCP) - Protocol: AmneziaWG (`amneziawg-go` on `utun8`), full tunnel (`0/1` and `128.0/1` via `utun8`) - DNS in the profile: AmneziaDNS (172.29.172.254) ### To reproduce 1. Connect over Wi-Fi. `scutil --dns` shows `nameserver[0] : 172.29.172.254`. 2. Plug a device into the Mac with a USB cable. A new interface appears (`en8` here), gets no DHCP lease and falls back to IPv4 link-local (169.254.x.x). configd logs several `network changed` events. 3. Name resolution stops and does not recover on its own. Reproduced twice in one night (2026-10-09, about 00:14 and 02:52 local time, UTC+4). The second time was done on purpose and measured. ### What I measured during the failure (02:52–02:53) - `scutil --dns`, resolver #1: `nameserver[0] : 192.168.1.1`, `if_index : 14 (en0)`. The AmneziaDNS address is gone, replaced by the DHCP-provided router address. `State:/Network/Global/DNS` shows the same. - System resolver (`dscacheutil -q host`): no answer. - `dig @192.168.1.1`: timeout. - `dig @172.29.172.254` (asked directly): answers normally. - `ping 1.1.1.1` through the tunnel: 0% loss. - The `amneziawg-go` process and the `0/1` / `128.0/1` routes were unchanged. The client did not reconnect or restore DNS by itself. So here the tunnel and the DNS server inside it keep working; the only thing broken is that the system resolver now points at the router, and that is unreachable for DNS while the tunnel is up. Separately, with the tunnel up, port 53 to 1.1.1.1 / 8.8.8.8 times out while ICMP to the same addresses passes, which is consistent with the `310.blockDNS` anchor mentioned above. Not measured: I did not check `ping`/`arp` for the gateway during the failure, so I cannot say whether the gateway ARP entry was also flushed as in the original report. The `dig @192.168.1.1` timeout could be either that or the DNS block. ### Recovery Turning Wi-Fi off and on made the client restart `amneziawg-go`; after that `scutil --dns` showed 172.29.172.254 again and everything worked, with the USB device still attached and `en8` still active on its link-local address. ### Expected After a network configuration change the client should re-apply its DNS settings (or reconnect), instead of leaving the system on the DHCP DNS that its own kill switch blocks.

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#1513

No description provided.

Rows
Columns