It sounds like the root problem here might be 3rd party (k3s, docker, etc) overriding the routing that the VPN client is producing. The Windows Edge VPN Client has a function where it will automatically examine the routing table and restore it so the desired networks traverse the VPN. It does this often (every minute or so?).
The Linux client does not have this feature, so any 3rd party thing that alters the routing table after the VPN connects may break it.
I’d suggest examining the routing table immediately after connecting the VPN and then a few times during the duration of the session to see if there are any changes.
It may also be that something changed recently with Ubuntu or other’s network setup scripts. In either case, the routing table results will be informative.
I believe I was running into this issue and was successfully able to gain VPN access after debugging with an AI agent. The cause seemed to be too many entries in the system routing table. As a contract developer, I’m running many projects with their own docker/ddev containers on my local machine. After pruning containers, running ddev-stop -all, I went from 202 routes with 47 veth interfaces down to 94 / 17, and I was able to successfully connect to the VPN.
The short version of the analysis supplied by the agent is that UIpForwardTable::SaveIpForwardTable() likely has a fixed limit on the number routing table entries it can handle, and it would be helpful if the Linux client can handle this more dynamically, or provide a more graceful failure message. I can provide the longer version of the analysis an suggestions if desired, I didn’t want to spam this thread now.