Does Libertine give Ubuntu Touch a phone-wide VPN?

Two questions get asked as one on Ubuntu Touch: will this desktop package run, and will the phone get a VPN. The container answers the first. Nothing in it answers the second, because a container has its own filesystem view while the network stack and its policy belong to the phone. Trace where each piece lives before promising a workflow.

Two questions that look like one

Running a desktop application inside a container is a packaging achievement. Making the phone's connection manager establish a tunnel, hold it across suspend and decide what happens when it drops is platform work. An installer that completes inside the container proves only that dependencies resolved there. It says nothing about whether the phone has an approved VPN plugin, whether the tunnel survives a reboot, or which applications use it.

Keep the two in separate sentences in any evaluation. Collapsing them is how a lab demo becomes a support commitment nobody can honour.

What the container boundary actually supplies

A Libertine container is a writable environment layered over a phone whose base system is read-only. That is why installing a package works there at all, and why the same install on the base system does not. It also runs applications in the foreground, integrated with the phone's display, and it is explicitly not a way to run server software or keep a process alive in the background. Those constraints matter for a VPN client, which is expected to stay up.

libertine-container-manager list
libertine-container-manager info -i <container-id>
libertine-launch -i <container-id> bash

The listing shows which containers exist, and the info command reports the distribution and installed state. The launch command gives you a shell inside, which is the right place to inspect what the package actually installed. What it does not give you is authority over the phone's networking. A binary inside the container that wants to create a tunnel needs a privileged interface, and that interface belongs to the platform, not to the container.

Where the phone's network state lives

Names, routes and connection profiles are managed by the phone's network service, outside any container. A tunnel entry appears there only when the platform supports that VPN type and the operator has installed the corresponding plugin.

nmcli connection show
ip route get 10.42.0.10
ip -br addr show

The connection listing is the authoritative answer to "is there a VPN profile on this phone". If your tunnel is absent from that list, no amount of work inside the container will make it appear. The route lookup answers a narrower question: which interface this phone would use for one destination. That is the check to repeat after any change, because a profile can exist and still not be the path a given application takes.

Read one workflow end to end

Pick the real task, such as reaching a private database with a desktop client. Then follow the flow: the application starts in the container, resolves the hostname through whatever resolver the phone uses, opens a socket, and the phone's routing decides which interface carries it. Each step has an owner. The container owns the application, the platform owns the resolver and routing, and the VPN endpoint owns authentication. A failure at any step is a failure of that step, not of the whole idea.

Test the private hostname and the private address separately. A name that resolves to a public address and an address that routes into a tunnel are different observations, and confusing them produces a report that cannot be reproduced.

What to record when the answer is no

Sometimes the honest conclusion is that this phone, on this release, cannot carry the workflow. Write that down with the evidence: which connection types the platform offers, which clients were tried, and which step failed.

Then state the alternative that was accepted, whether that is a different device, a different access method, or a narrower task that stays inside the container without touching private networks.

Resist the temptation to remount the base system or grant unexplained privileges to reproduce an old recipe. A phone that boots is not the same as a phone whose network policy you can still reason about six months later.