[GH-ISSUE #2869] [VLESS] [Ubuntu 24.04] systemd-resolved crashes with 'start-limit-hit' when split tunneling is enabled #1305

Open
opened 2026-10-13 20:39:51 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @MichaelGr on GitHub (Jul 24, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2869

Describe the bug
When split tunneling is enabled on Ubuntu 24.04, the systemd-resolved.service crashes due to a restart loop, leading to a complete DNS resolution failure (e.g., YouTube and other domains stop resolving).

The system logs show that systemd-resolved.service hits its start limit because the client (or associated scripts) triggers service restarts too rapidly. Manually starting the service afterwards temporarily fixes the issue.

To Reproduce
Steps to reproduce the behavior:

  1. Connect to a VLESS server on Ubuntu 24.04.
  2. Enable Split Tunneling mode.
  3. Attempt to open a website (e.g., YouTube) and observe that DNS resolution fails.
  4. Check service status via sudo systemctl status systemd-resolved.service.
  5. See the error: Failed with result 'start-limit-hit'.
  6. Fix temporarily by running: sudo systemctl enable --now systemd-resolved.service

Expected behavior
Enabling or disabling split tunneling modes should handle DNS configuration smoothly without causing systemd-resolved.service to rapidly restart, trigger rate limits, and crash.

Log files
systemd-resolved service failure state:

systemd-resolved.service: Start request repeated too quickly.
systemd-resolved.service: Failed with result 'start-limit-hit'

Reference Routing Table (Split Tunneling Enabled):

0.0.0.0/1 via 10.33.0.2 dev tun2 scope link
default via 192.168.0.1 dev enp3s0 proto dhcp src 192.168.0.193 metric 100
8.8.4.4 via 10.33.0.2 dev tun2 scope link
10.33.0.0/24 dev tun2 proto kernel scope link src 10.33.0.2
100.64.0.1 via 10.33.0.2 dev tun2 scope link
128.0.0.0/1 via 10.33.0.2 dev tun2 scope Link

Reference Routing Table (Split Tunneling Disabled):

default via 192.168.0.1 dev enp3s0 proto dhcp src 192.168.0.193 metric 100
1.0.0.0/8 via 10.33.0.2 dev tun2 scope link
2.0.0.0/7 via 10.33.0.2 dev tun2 scope link
4.0.0.0/6 via 10.33.0.2 dev tun2 scope link
8.0.0.0/5 via 10.33.0.2 dev tun2 scope link
8.8.4.4 via 10.33.0.2 dev tun2 scope link
10.33.0.0/24 dev tun2 proto kernel scope link src 10.33.0.2
16.0.0.0/4 via 10.33.0.2 dev tun2 scope link
32.0.0.0/3 via 10.33.0.2 dev tun2 scope link
64.0.0.0/2 via 10.33.0.2 dev tun2 scope link
100.64.0.1 via 10.33.0.2 dev tun2 scope link
128.0.0.0/1 via 10.33.0.2 dev tun2 scope link

Desktop:

  • OS: Ubuntu 24.04.4 LTS
  • Version: 4.8.21.0

Server:

  • OS: Ubuntu 24.04.4 LTS

Additional context
The issue is strictly related to how AmneziaVPN interacts with systemd-resolved when modifying the routing table and DNS parameters during the split tunneling state transition. The application triggers too many rapid restart requests for the service, hitting systemd's default protective rate limits.

Originally created by @MichaelGr on GitHub (Jul 24, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2869 **Describe the bug** When split tunneling is enabled on Ubuntu 24.04, the `systemd-resolved.service` crashes due to a restart loop, leading to a complete DNS resolution failure (e.g., YouTube and other domains stop resolving). The system logs show that `systemd-resolved.service` hits its start limit because the client (or associated scripts) triggers service restarts too rapidly. Manually starting the service afterwards temporarily fixes the issue. **To Reproduce** Steps to reproduce the behavior: 1. Connect to a VLESS server on Ubuntu 24.04. 2. Enable Split Tunneling mode. 3. Attempt to open a website (e.g., YouTube) and observe that DNS resolution fails. 4. Check service status via `sudo systemctl status systemd-resolved.service`. 5. See the error: `Failed with result 'start-limit-hit'`. 6. Fix temporarily by running: `sudo systemctl enable --now systemd-resolved.service` **Expected behavior** Enabling or disabling split tunneling modes should handle DNS configuration smoothly without causing `systemd-resolved.service` to rapidly restart, trigger rate limits, and crash. **Log files** `systemd-resolved` service failure state: ```text systemd-resolved.service: Start request repeated too quickly. systemd-resolved.service: Failed with result 'start-limit-hit' ``` Reference Routing Table (Split Tunneling **Enabled**): ```text 0.0.0.0/1 via 10.33.0.2 dev tun2 scope link default via 192.168.0.1 dev enp3s0 proto dhcp src 192.168.0.193 metric 100 8.8.4.4 via 10.33.0.2 dev tun2 scope link 10.33.0.0/24 dev tun2 proto kernel scope link src 10.33.0.2 100.64.0.1 via 10.33.0.2 dev tun2 scope link 128.0.0.0/1 via 10.33.0.2 dev tun2 scope Link ``` Reference Routing Table (Split Tunneling **Disabled**): ```text default via 192.168.0.1 dev enp3s0 proto dhcp src 192.168.0.193 metric 100 1.0.0.0/8 via 10.33.0.2 dev tun2 scope link 2.0.0.0/7 via 10.33.0.2 dev tun2 scope link 4.0.0.0/6 via 10.33.0.2 dev tun2 scope link 8.0.0.0/5 via 10.33.0.2 dev tun2 scope link 8.8.4.4 via 10.33.0.2 dev tun2 scope link 10.33.0.0/24 dev tun2 proto kernel scope link src 10.33.0.2 16.0.0.0/4 via 10.33.0.2 dev tun2 scope link 32.0.0.0/3 via 10.33.0.2 dev tun2 scope link 64.0.0.0/2 via 10.33.0.2 dev tun2 scope link 100.64.0.1 via 10.33.0.2 dev tun2 scope link 128.0.0.0/1 via 10.33.0.2 dev tun2 scope link ``` **Desktop:** - OS: Ubuntu 24.04.4 LTS - Version: 4.8.21.0 **Server:** - OS: Ubuntu 24.04.4 LTS **Additional context** The issue is strictly related to how AmneziaVPN interacts with `systemd-resolved` when modifying the routing table and DNS parameters during the split tunneling state transition. The application triggers too many rapid restart requests for the service, hitting systemd's default protective rate limits.
Author
Owner

@maruslera-svg commented on GitHub (Aug 7, 2026):

I confirm. I have exactly the same problem.

<!-- gh-comment-id:5213559285 --> @maruslera-svg commented on GitHub (Aug 7, 2026): I confirm. I have exactly the same problem.
Sign in to join this conversation.
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#1305
No description provided.