Re: openvpn.conf working on the CLI and with systemd but not with NM: wrong IPv6 setting when configuring the tun interface?

On Thu, 2021-06-03 at 17:44 +0200, Beniamino Galvani wrote:
On Thu, Jun 03, 2021 at 07:17:31AM +0000, Samuel Le Thiec via networkmanager-list wrote:


For a moment I thought that Network Manager may be assuming a point-to-point topology
the VPN instead of the "topology subnet" as specified in the server.conf, so I did try
'push "topology subnet"' to the clients, but it didn't help: without the 'push "route-
.."' above, the client is still missing the route to the subnet.

Right, 'topology' has no effect for IPv6.

I can totally live with that, but is it the expected behaviour? If so, why does it
differ from starting openvpn manually from the cli or even as a systemd

It's not expected. I think the NetworkManager OpenVPN plugin parses
the IPv6 configuration incorrectly. If the server pushes, for example:

  ifconfig-ipv6 2001:db8:f00:bebe::1003/64 2001:db8:f00:bebe::1

NetworkManager considers the first argument as the subnet and the
second as the peer, and so it does something equivalent to:

  ip addr add dev tun0 2001:db8:f00:bebe::1003/64 peer 2001:db8:f00:bebe::1

which appears in the "ip -6 addr" output as:

    inet6 2001:db8:f00:bebe::1003 peer 2001:db8:f00:bebe::1/128 scope global
       valid_lft forever preferred_lft forever

Instead, according to 'man openvpn', NM should simply add address
"2001:db8:f00:bebe::1003/64" and use the second argument as a fallback
gateway for the routes specified by '--route-ipv6':

      --ifconfig-ipv6 ipv6addr/bits ipv6remote
            configure IPv6 address ipv6addr/bits on the ``tun'' device.  The
            second parameter is used as route target for --route-ipv6 if  no
            gateway is specified.

     --route-ipv6 ipv6addr/bits [gateway] [metric]
            setup IPv6 routing in the system to send the specified IPv6 net-
            work into OpenVPN's ``tun''.  The gateway parameter is only used
            for  IPv6  routes  across  ``tap''  devices, and if missing, the
            ``ipv6remote'' field from --ifconfig-ipv6 is used.

I have opened an issue for this [1] and I will prepare a patch for it.



Hello Beniamino,

This seems great, thank you!

On a unrelated subject, may I ask here why NM tries to reroute everything through the vpn
by default instead of letting the vpn server decide of the default behaviour?

I find it somewhat counterintuitive but there's certainly a good reason!

Thanks again,


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]