Public bug reported: A common use case is setting up a VPN connection as a secondary to primary connection (wired or wireless). At times the VPN connection may fail for various reason: temporary unavailability, timeout, just a network "hiccup". That prevents the primary interface from being brought up.
In another scenario when the connection is initially established and at a later stage secondary connection fails the primary connection remains up. This is a desired behavior and maybe it could be reflected with establishing the connection initially? Maybe temporary failure of the secondary should not prevent the primary from being brought up. [ Test Plan ] 1. Set up VPN connection with incorrect data (to simulate failed connection): nmcli con add type vpn con-name vpn0 vpn-type openvpn -- vpn.data "remote=203.0.113.1,port=1194,dev=tun,proto=udp" vpn.secrets "password=wrong" 2. Add primary connection: nmcli con add type ethernet ifname enp5s0 con-name phys0 ipv4.method auto ipv6.method ignore 3. Add the VPN connection as secondary and check whether it has been added: nmcli con modify phys0 connection.secondaries vpn0 nmcli -f connection.secondaries con show phys0 4. Restart the primary connection: nmcli con down phys0 nmcli con up phys0 [ Actual result ] The primary connection is not being brought up due to secondary failing. Please note that in this case VPN failure is intentional (random/incorrect data), but in real world scenario VPN connection fails at times for various reasons. [ Expected result ] Bring up the primary interface, try to perform attempts to establish secondary at a later stage (e.g. using exponential backoff?). The bug is reported upstream at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/work_items/1901 ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Affects: network-manager (Ubuntu Jammy) Importance: Undecided Status: New ** Affects: network-manager (Ubuntu Noble) Importance: Undecided Status: New ** Affects: network-manager (Ubuntu Resolute) Importance: Undecided Status: New ** Affects: network-manager (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: network-manager (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: network-manager (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: network-manager (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: network-manager (Ubuntu Stonking) Importance: Undecided Status: New ** Description changed: A common use case is setting up a VPN connection as a secondary to primary connection (wired or wireless). At times the VPN connection may fail for various reason: temporary unavailability, timeout, just a network "hiccup". That prevents the primary interface from being brought up. In another scenario when the connection is initially established and at a later stage secondary connection fails the primary connection remains up. This is a desired behavior and maybe it could be reflected with establishing the connection initially? Maybe temporary failure of the secondary should not prevent the primary from being brought up. [ Test Plan ] 1. Set up VPN connection with incorrect data (to simulate failed connection): nmcli con add type vpn con-name vpn0 vpn-type openvpn -- vpn.data "remote=203.0.113.1,port=1194,dev=tun,proto=udp" vpn.secrets "password=wrong" 2. Add primary connection: nmcli con add type ethernet ifname enp5s0 con-name phys0 ipv4.method auto ipv6.method ignore 3. Add the VPN connection as secondary and check whether it has been added: nmcli con modify phys0 connection.secondaries vpn0 nmcli -f connection.secondaries con show phys0 4. Restart the primary connection: nmcli con down phys0 nmcli con up phys0 [ Actual result ] The primary connection is not being brought up due to secondary failing. Please note that in this case VPN failure is intentional (random/incorrect data), but in real world scenario VPN connection fails at times for various reasons. [ Expected result ] Bring up the primary interface, try to perform attempts to establish secondary at a later stage (e.g. using exponential backoff?). + + The bug is reported upstream at + https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/work_items/1901 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2161316 Title: Secondary connection failure prevents primary connection from being established To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2161316/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
