On Wed, 2014-07-16 at 10:51 +0200, D.S. Ljungmark wrote:
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?
I think both methods should be reliable (provided your dispatcher-script behaves correctly). connection.secondaries seams easier to me. Thomas
On 16 Jul 2014 10:43, "Thomas Haller" <thaller redhat com> wrote:
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