That sounds like a working method. I'm less worried about the cleartext hole as the VPN is for internal and debugging use.
Dispatcher vs making the default connection persistent are about the same, which method is better supported and gives better guarantees that things work reliably?
On Wed, 2014-07-16 at 10:30 +0200, D.S. Ljungmark wrote:
> Ah. That means we have to deploy the primary connections as well.
> Right now those are auto generated and not stored persistently.
>
> I'll try that, any thing else I can try?
>
> On 16 Jul 2014 10:24, "Thomas Haller" <thaller redhat com> wrote:
> On Wed, 2014-07-16 at 02:59 +0200, D.S. Ljungmark wrote:
> > So, I have now something that works.
> >
> > it can connect to vpn manually.
> >
> > Next up, how do I get autoconnect to work? I thought
> > "connection.autoconnect" was enough, but appearantly that's
> not the case.
> >
> > What am I missing? ipv4 + ipv6 network comes up normally as
> it should.
>
>
> [[ I did not test this myself, but I think... ]]
>
> connection.autoconnect is ignored by VPN type connections.
>
> What might work for you, is setting the
> "connection.secondaries" option
> of the parent ethernet/wifi-connection. One downside of this
> is that the
> parent connection is not part of the VPN-keyfile that you want
> to
> deploy.
>
>
> Thomas
You could also use dispatcher scripts. See `man NetworkManager`.
You need to enable NetworkManager-dispatcher service (not sure how that
works on Debian. On Fedora you would `systemctl enable
NetworkManager-dispatcher`. Maybe it already works).
then ads a root-owned script -- with proper access rights(?) --
to /etc/NetworkManager/dispatcher.d
It can react on the status changes and call `nmcli connection up id
my-vpn`.
Downside: if for some reason the establishing of the VPN fails, users
might communicate insecurely. And there is a short time after the parent
interface connects, where the traffic does not yet go over the VPN.
I think you could work around that, by setting never-default=no in the
parent connection and/or not configuring any routes there
(ignore-auto-routes?)... but then you must again deploy a parent
connection...
Thomas