Can this NetworkManager plugin run two VPNs at once?

Two VPN entries sit in the connection list, both say connected, and only one of them carries the traffic you expected. Or the second refuses to start at all, and nobody can say whether that is the plugin, the client or a policy you forgot. Claims about a one-VPN limit describe particular implementations, and implementations differ. Walk the capability first, then the coordination.

Count saved profiles, then count activations

A saved profile is a configuration object, and an active connection is a running instance. The list merges the two concepts visually, which is why both reports sound true. Start by naming the exact objects with their UUIDs, because the display name is not unique and an old import often shares a label with a newer entry. Then check the active list separately and see which UUIDs appear. Only then do you know whether you are comparing two configurations or two live tunnels.

Activating the same UUID twice is a third case again, and it is not concurrency. It is a reactivation of one instance.

Read the plugin's own metadata

Each VPN plugin ships a small metadata file that the manager reads, and those files can declare whether the plugin supports several connections at once. Read the file installed on this machine rather than repeating what an upstream project currently writes, because the distribution package decides what you actually have. The same check applies per protocol: an answer for one plugin says nothing about another. Record the package version alongside the result, so a later comparison means something.

Old advice about a single-VPN limit was describing older integrations. It is neither permanently true nor safe to assume as fixed, and the file in front of you settles it locally.

Concurrent is not coordinated

Two plugins starting successfully proves the capability, not the design. Two tunnels that both offer a default route will compete, and the one that installed its route last usually wins without announcing that it did. Overlapping private ranges have the same problem in a smaller shape.

Decide which destinations belong to which profile before activating anything. Renaming a profile does not distinguish the destinations.

DNS picks a winner whether you do or not

Resolver settings are per profile, and when two are active the resolution order is decided by policy and priority rather than by intent. The profile that came up last can quietly own every corporate name.

Assign each private namespace to the resolver that should answer for it, and set routing preference deliberately instead of relying on order. Then test a name from each namespace with both tunnels up, and again with one of them disconnected. A resolver that only works while both tunnels are up is a design that will surprise someone at the worst possible moment.

Roll out in a fixed order and inspect between

Activate one profile, inspect its route and resolver state, then activate the second and inspect again. Comparing the two states tells you what changed and which profile owns what. Do not activate both and then diagnose the result.

Test each required resource through the tunnel that should carry it, then disconnect one profile and confirm the other keeps its routes, its DNS and its intended failure behaviour. If the deployed plugin genuinely cannot do what you need, choose a supported upgrade or an explicitly isolated alternative rather than reviving an obsolete protocol beside the manager. A second, separate tunnel that nobody manages is not isolation; it is another source of surprising routes.