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
Attachment:
signature.asc
Description: This is a digitally signed message part