REPRODUCIBILITY: 100%
OS VERSION: 5.2.0.15
HARDWARE: Jolla Phone (jp2601, “Jolla Phone 2026”), SoC MediaTek MT6858, kernel 6.12.38-4k
UI LANGUAGE: English
REGRESSION: No — WireGuard is a 5.0+ feature; behaviour present since it was added
DESCRIPTION:
Component: connman-vpn (WireGuard) — routing.
Steps to reproduce: configure a WireGuard VPN whose peer routes a remote subnet in addition to the tunnel subnet, e.g.
[Peer]
AllowedIPs = 192.168.2.0/24, 10.10.0.0/24
[Interface]
Address = 10.10.0.10/24
Connect the tunnel, then check the routing table.
Actual result: the tunnel comes up and the wg interface gets its inner address (wgN = 10.10.0.10/24), so only the connected 10.10.0.0/24 is routable. There is no route for 192.168.2.0/24 — connman-vpn does not install routes for the peer’s other AllowedIPs subnets. Traffic to 192.168.2.0/24 therefore falls back to the default route and never enters the tunnel (confirmed: ip route has no 192.168.2.0/24 entry; the WireGuard server sees no packets for it).
Expected result: connman-vpn installs system routes for all of a peer’s AllowedIPs subnets when the tunnel comes up, as wg-quick does on desktop Linux.
Workaround: add the route by hand after connecting — ip route add 192.168.2.0/24 dev wgN — after which the remote subnet is reachable through the tunnel. The manual route does not persist across reconnects.
Additional information: distinct from thread 27081 (“Wireguard User Routes not persisted”), which is about UI-added custom User Routes disappearing on save; this is the peer’s AllowedIPs subnet routes never being installed at all. Part of a set of IPv6-only-mobile WireGuard issues on the Jolla Phone 2026 (SFOS 5.2), filed separately — connmand SIGSEGV on WG connect (thread 30643); mobile data comes up IPv6-only (thread 11917); WireGuard import truncates a bracketed IPv6 endpoint; and the mobile-data usage counter reads 0 for IPv6-only traffic.