Re: openvpn.conf working on the CLI and with systemd but not with NM: wrong IPv6 setting when configuring the tun interface?
Hello again:) I don't know why this would be needed, but I noticed this can be worked around by pushing the route towards the server-ipv6 subnet from the openvpn server, with the directive: push "route-ipv6 2001:bc8:3d1d:1337::/64" 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 openvpn-client@.service? Thanks in advance! samuel On Tue, 2021-06-01 at 13:27 +, Samuel Le Thiec via networkmanager-list wrote: > Note: sorry for the potential duplicate email, I sent it before & after having > registered to the list! > > Hello all, > > I have a working openvpn config (see below) which I can't get to fully work > with Network > Manager: the private IPv6 network is not accessible when connecting to the > VPN with > NM(*). > > Here is what I get for tun0 when connecting with NM: > > > $ ip a l tun0 > 17: tun0: mtu 1500 qdisc fq_codel > state > UNKNOWN > group default qlen 500 > link/none > inet 10.66.6.4/24 brd 10.66.6.255 scope global noprefixroute tun0 > valid_lft forever preferred_lft forever > inet6 2001:bc8:3d1d:1337::1002 peer 2001:bc8:3d1d:1337::1/64 scope global > noprefixroute > valid_lft forever preferred_lft forever > > > When connecting with systemd or via the command line (sudo openvpn --config > vpn.conf) : > > $ ip a l tun0 > > 14: tun0: mtu 1500 qdisc fq_codel > state > UNKNOWN > group default qlen 500 > link/none > > inet 10.66.6.4/24 scope global tun0 > > valid_lft forever preferred_lft forever > > inet6 2001:bc8:3d1d:1337::1002/64 scope global > valid_lft forever preferred_lft forever > inet6 fe80::24b7:bb72:a319:252d/64 scope link stable-privacy > valid_lft forever preferred_lft forever > > > → Note the scope global inet6 differences above: peer vs subnet > > (*) In order to avoid having all my trafic routed through the vpn, I did > check "Use this > connection only for resources on its network" for IPv4 & IPv6. > > Is there a way to make Network Manager behave like openvpn --config vpn.conf? > > Here is additionnal informations: > > > $ nmcli device show tun0 > GENERAL.DEVICE: tun0 > GENERAL.TYPE: tun > GENERAL.HWADDR: (unknown) > GENERAL.MTU: 1500 > GENERAL.STATE: 100 (connected (externally)) > GENERAL.CONNECTION: tun0 > GENERAL.CON-PATH: > /org/freedesktop/NetworkManager/ActiveConnection/27 > IP4.ADDRESS[1]: 10.66.6.4/24 > IP4.GATEWAY: -- > IP4.ROUTE[1]: dst = 10.66.6.0/24, nh = 0.0.0.0, mt > = 50 > IP6.ADDRESS[1]: 2001:bc8:3d1d:1337::1002/64 > IP6.GATEWAY: -- > IP6.ROUTE[1]: dst = 2001:bc8:3d1d:1337::1/128, nh = > ::, mt = > 256 > IP6.ROUTE[2]: dst = 2001:bc8:3d1d:1337::1002/128, > nh = ::, mt > = > 50 > IP6.ROUTE[3]: dst = 2001:bc8:3d1d:1337::1/128, nh = > ::, mt = > 50 > > > And the openvpn client config I imported from NM (minus the certs): > | client > | dev tun > | # try standard port first > | remote hub.nsoc.fr > | remote hub.nsoc.fr 53 > | ping 25 > | ping-restart 120 > | persist-key > | persist-tun > | tls-version-min 1.3 > | remote-cert-tls server > | mute-replay-warnings > | > | askpass > | verb 3 > | > | > | > | > | > > > Thank you in advance! > > Samuel > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Support for Intel Active Management Technology over wireless in Linux
On Thu, 2021-05-27 at 21:40 +0300, Emmanuel Grumbach via networkmanager-list wrote: > > Disclaimer: This feature is available only on vPRO Platforms. > > Question to the NM maintainers: > Would you consider merging patches that would implement this? Definitely. The most important property for implementing a feature is that the underlying dependencies are also open soure and merged upstream. In this case, the requirement is that (upstream) kernel and (upstream) wpa_supplicant can support this feature -- or at least, there is a real possibility that it will support it in the future. That you need a special hardware is fine. It however poses a practical problem if upstream contributors cannot test/contribute to it. It basically means that those contibutors who care about this feature (and can test it) need to carry more burden than usual. > Do you see any blocker to implement this? Maybe the handling of RFKILL in NetworkManager requires some cleanup first. That would be in `src/core/nm-manager.c` and `src/core/rf-kill- manager.c`. Your description is very detailed. Thank you. It does not sound entirely trivial to me however :). NetworkManager is mostly about having connection profiles and activating them. It's not clear to me how this ATM fits with that model. Would the user still configure a connection profile? Should a connection profile be auto-generated (there are cases where wo do that, for example for bluetooth paired devices). > Any recommendation for the implementation? NetworkManager does talk relatively little nl80211 to kernel. Mostly it only configures wpa_supplicant. And most things happen when "activating" a profile in NetworkManager. I don't have concrete suggestions. Did you look at NetworkManager alraeady? Maybe we can find first "simpler" steps and break this down? best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
openvpn.conf working on the CLI and with systemd but not with NM: wrong IPv6 setting when configuring the tun interface?
Note: sorry for the potential duplicate email, I sent it before & after having registered to the list! Hello all, I have a working openvpn config (see below) which I can't get to fully work with Network Manager: the private IPv6 network is not accessible when connecting to the VPN with NM(*). Here is what I get for tun0 when connecting with NM: $ ip a l tun0 17: tun0: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 10.66.6.4/24 brd 10.66.6.255 scope global noprefixroute tun0 valid_lft forever preferred_lft forever inet6 2001:bc8:3d1d:1337::1002 peer 2001:bc8:3d1d:1337::1/64 scope global noprefixroute valid_lft forever preferred_lft forever When connecting with systemd or via the command line (sudo openvpn --config vpn.conf) : $ ip a l tun0 14: tun0: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 10.66.6.4/24 scope global tun0 valid_lft forever preferred_lft forever inet6 2001:bc8:3d1d:1337::1002/64 scope global valid_lft forever preferred_lft forever inet6 fe80::24b7:bb72:a319:252d/64 scope link stable-privacy valid_lft forever preferred_lft forever → Note the scope global inet6 differences above: peer vs subnet (*) In order to avoid having all my trafic routed through the vpn, I did check "Use this connection only for resources on its network" for IPv4 & IPv6. Is there a way to make Network Manager behave like openvpn --config vpn.conf? Here is additionnal informations: $ nmcli device show tun0 GENERAL.DEVICE: tun0 GENERAL.TYPE: tun GENERAL.HWADDR: (unknown) GENERAL.MTU: 1500 GENERAL.STATE: 100 (connected (externally)) GENERAL.CONNECTION: tun0 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/27 IP4.ADDRESS[1]: 10.66.6.4/24 IP4.GATEWAY: -- IP4.ROUTE[1]: dst = 10.66.6.0/24, nh = 0.0.0.0, mt = 50 IP6.ADDRESS[1]: 2001:bc8:3d1d:1337::1002/64 IP6.GATEWAY: -- IP6.ROUTE[1]: dst = 2001:bc8:3d1d:1337::1/128, nh = ::, mt = 256 IP6.ROUTE[2]: dst = 2001:bc8:3d1d:1337::1002/128, nh = ::, mt = 50 IP6.ROUTE[3]: dst = 2001:bc8:3d1d:1337::1/128, nh = ::, mt = 50 And the openvpn client config I imported from NM (minus the certs): | client | dev tun | # try standard port first | remote hub.nsoc.fr | remote hub.nsoc.fr 53 | ping 25 | ping-restart 120 | persist-key | persist-tun | tls-version-min 1.3 | remote-cert-tls server | mute-replay-warnings | | askpass | verb 3 | | | | | Thank you in advance! Samuel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
openvpn.conf working on the CLI and with systemd but not with NM: wrong IPv6 setting when configuring the tun interface?
Hello all, Please, make sure to CC me in your replies so I'm sure to get them! I have a working openvpn config (see below) which I can't get to fully work with Network Manager: the private IPv6 network is not accessible when connecting to the VPN with NM(*). Here is what I get for tun0 when connecting with NM: $ ip a l tun0 17: tun0: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 10.66.6.4/24 brd 10.66.6.255 scope global noprefixroute tun0 valid_lft forever preferred_lft forever inet6 2001:bc8:3d1d:1337::1002 peer 2001:bc8:3d1d:1337::1/64 scope global noprefixroute valid_lft forever preferred_lft forever When connecting with systemd or via the command line (sudo openvpn --config vpn.conf) : $ ip a l tun0 14: tun0: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 10.66.6.4/24 scope global tun0 valid_lft forever preferred_lft forever inet6 2001:bc8:3d1d:1337::1002/64 scope global valid_lft forever preferred_lft forever inet6 fe80::24b7:bb72:a319:252d/64 scope link stable-privacy valid_lft forever preferred_lft forever → Note the scope global inet6 differences above: peer vs subnet (*) In order to avoid having all my trafic routed through the vpn, I did check "Use this connection only for resources on its network" for IPv4 & IPv6. Is there a way to make Network Manager behave like openvpn --config vpn.conf? Here is additionnal informations: $ nmcli device show tun0 GENERAL.DEVICE: tun0 GENERAL.TYPE: tun GENERAL.HWADDR: (unknown) GENERAL.MTU:1500 GENERAL.STATE: 100 (connected (externally)) GENERAL.CONNECTION: tun0 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/27 IP4.ADDRESS[1]: 10.66.6.4/24 IP4.GATEWAY:-- IP4.ROUTE[1]: dst = 10.66.6.0/24, nh = 0.0.0.0, mt = 50 IP6.ADDRESS[1]: 2001:bc8:3d1d:1337::1002/64 IP6.GATEWAY:-- IP6.ROUTE[1]: dst = 2001:bc8:3d1d:1337::1/128, nh = ::, mt = 256 IP6.ROUTE[2]: dst = 2001:bc8:3d1d:1337::1002/128, nh = ::, mt = 50 IP6.ROUTE[3]: dst = 2001:bc8:3d1d:1337::1/128, nh = ::, mt = 50 And the openvpn client config I imported from NM (minus the certs): | client | dev tun | # try standard port first | remote hub.nsoc.fr | remote hub.nsoc.fr 53 | ping 25 | ping-restart 120 | persist-key | persist-tun | tls-version-min 1.3 | remote-cert-tls server | mute-replay-warnings | | askpass | verb 3 | | | | | Thank you in advance! Samuel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhclient-${IFNAME}.conf stopped working after upgrade FC32 -> FC34
Hi,
First of all, as always: enable level=TRACE logging and look at the
logs and have them ready for inspection. Read [1] for hints about
logging.
[1]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/bae22a45d837e76e805f0f411b2d71748e76625e/contrib/fedora/rpm/NetworkManager.conf#L27
1) you already found the [main].dhcp setting. See `man
NetworkManager.conf`. So, this probably does not apply to you. Still:
If you configure [main].dhcp=dhclient, then NetworkManager uses
dhclient DHCP plugin. That involves reading files from /etc/dhcp and
merging them. This was, the user can hack the behavior of dhclient.
This did not change between Fedora 32 and Fedora 34.
What might have changed, is the default setting for [main].dhcp. Since
NetworkManager 1.18, the default changed from [main].dhcp=dhclient to
[main].dhcp=internal. But that did not happen in Fedora 32. So it's not
clear why this would behave different. Also, you might have had another
application that dropped a configuration snippet to
/{usr/lib,run,etc}/NetworkManager/conf.d, which is now gone? Anyway,
check that the desired right DHCP plugin is used.
2) what might have changed is how certain options get merged from
/etc/dhcp. Enable `level=TRACE` logging. See how dhclient gets spawned.
Note the configuration file that NetworkManager generated. Check what
differs or what is missing (if anything).
3)
> $ nmcli c m $UUID 'DHCP4.OPTION+=supersede domain-name-servers=(127.0.0.1)'
this does not work. The upper case optoins are not settings of the
profile. Instead these are run-time information of the device (display
only). The way to configure NetworkManager is by configuring settings
of the connection profile, that is the lower case options in nmcli
Except, bypassing that API by instructing dhclient in /etc/dhcp
directly as you did earlier.
4) I did try :
'set ipv4.dns 127.0.0.1
save persistant
'
I think you would still the the DNS settings form DHCP. Disable that
with
nmcli connection modify "$PROFILE"
ipv4.ignore-auto-dns yes ipv6.ignore-auto-dns yes
Of course, if all you want is 127.0.0.1 and this is a very static
configuration, then there is no problem with telling NetworkManager not
to configure /etc/resolv.conf. The best way is to make /etc/resolv.conf
as symlink to /etc/my-resolv.conf. That automatically tells
NetworkManager to stay away. Otherwise, configure [main].dns=unmanaged.
See the [main].dns, [main].rc-manager and [main].systemd-resolved
options in `man NetworkManager.conf`.
best,
Thomas
On Mon, 2021-05-31 at 16:17 +0100, Jason Vas Dias via networkmanager-
list wrote:
> I did try :
> 'set ipv4.dns 127.0.0.1
> save persistant
> '
> in 'nmcli c e $uuid', but this did not work either after an up / down
> -
> /etc/resolv.conf was not updated to contain only '127.0.0.1' - it did
> ALSO contain '127.0.0.1', but as a suffix, not a prefix - this is not
> what I want .
> This did used to work with my old setup on FC32, but not on FC34 .
> Is there any custom dhclient.conf file that is included in the current
> implementation anymore ?
> Thanks, Jason
>
> On 31/05/2021, Jason Vas Dias wrote:
> >
> > Good day -
> >
> > On an FC32 x86_64 box, which I just successfully upgraded to FC34 ,
> > now running NM 1.30.4-1.fc34.x86_64 :
> > I had some custom dhclient configuration files, which used to be
> > honored
> > by NM - ie. they took effect before upgrade, but not after:
> >
> > /etc/dhcp/{dhclient-ens1u2u4.conf,dhclient-wlp59s0.conf}
> >
> > which contain:
> >
> > dhclient.ens1u2u4.conf :
> >
> > interface "ens1u2u4" {
> > send dhcp-client-identifier 34:48:ed:a8:7c:be;
> > send host-name "jvdspc.jvds.net";
> > supersede domain-name-servers 127.0.0.1;
> > }
> >
> >
> > dhclient.wlp59s0.conf :
> > interface "wlp59s0" {
> > send dhcp-client-identifier 5c:80:b6:72:cb:7b;
> > send host-name "jvdspc.jvds.net";
> > supersede domain-name-servers 127.0.0.1;
> > }
> >
> >
> > There are links to these files in /etc/dhclient-
> > {ens1u2u4,wlp59s0}.conf ,
> > and
> > /etc/dhclient.{ens1u2u4,wlp59s0}.conf .
> >
> > These files used to be merged in to the effective DHCP client
> > configuration , on FC32, and all prior FC & RHEL releases I've
> > used, in:
> > /var/lib/NetworkManager/dhclient-{ens1u2u4,wlp59s0}.conf
> > , in use for each interface, which is written for each 'up'
> > transition,
> > but no longer.
> >
> > I have in /etc/NetworkManager/NetworkManager.conf:
> >
> > [main]
> > #plugins=ifcfg-rh
> > dhcp=dhclient
> >
> >
> > I want to run my own ISC BIND caching nameserver,
> > which serves some authoritative zones and some RPZ (response
> > policy) zones
> > ,
> > and also tell any Dynamic DNS configured DHCP servers what I
> > consider
> > my domain name to be.
> >
> > I already had to disable systemd-resolved service after the
> > upgrade, which
> > also
> > broke using my own nameserver.
> >
> > Please can
Re: Support for Intel Active Management Technology over wireless in Linux
On Tue, Jun 1, 2021 at 8:26 PM Thomas Haller wrote: > > On Thu, 2021-05-27 at 21:40 +0300, Emmanuel Grumbach via > networkmanager-list wrote: > > > > Disclaimer: This feature is available only on vPRO Platforms. > > > > Question to the NM maintainers: > > Would you consider merging patches that would implement this? > > Definitely. The most important property for implementing a feature is > that the underlying dependencies are also open soure and merged > upstream. In this case, the requirement is that (upstream) kernel and > (upstream) wpa_supplicant can support this feature -- or at least, > there is a real possibility that it will support it in the future. Sure, the kernel patches will be included in 5.14. > > That you need a special hardware is fine. It however poses a practical > problem if upstream contributors cannot test/contribute to it. It > basically means that those contibutors who care about this feature (and > can test it) need to carry more burden than usual. I don't expect to have many more contributors than Intel itself :) We will work on this: write the code, test it etc... If there is a testing infra for the NetworkManager, we can see how we can add test to this infra etc... But I agree, contributors that don't have the setup will be in trouble. > > > > Do you see any blocker to implement this? > > Maybe the handling of RFKILL in NetworkManager requires some cleanup > first. That would be in `src/core/nm-manager.c` and `src/core/rf-kill- > manager.c`. Sure, I guess we can cope with that. > > Your description is very detailed. Thank you. It does not sound > entirely trivial to me however :). > > NetworkManager is mostly about having connection profiles and > activating them. It's not clear to me how this ATM fits with that > model. Would the user still configure a connection profile? Should a > connection profile be auto-generated (there are cases where wo do that, > for example for bluetooth paired devices). Yes, of course, the NetworkManager will still have connection profiles. That's the whole point of the RFKILL thing. NetworkManager has connection profiles configured say: 1) myAP@home 2) MyEmployerEnterpriseNetwork 3) MyPhoneHotspot AMT on the system's chipset also has profiles. Now, since AMT is more an enterprise feature, you will have only the profile number 2 configured there. Note that NetworkManager has no clue about what profiles are configured in AMT. We could do some profile sync, but this is out of scope (for now - but there is a user space service that knows how to talk to the NetworkManager through D-BUS that could possibly do that https://github.com/intel/lms). Just imagine that before giving you your machine, the IT department of your company configured the profile 2) in AMT through the BIOS, and then you install a Linux distro on your system. Fine. Now we get into the flow I described: your machine boots while AMT is having an active TCP connection. Because of that, AMT will tell the kernel not to touch the device because we want not to break the TCP connection, and the NM gets RFKILL. Here's where NM gets into action. It looks at the profile that AMT is associated to. This profile is 2). It fetches the frequency and the BSSID of the AP we're connected to in that ESSID. Profile 2 is supported by NM (it was configured as a connection profile), so NM *knows* that it can connect to that profile. This means that NM can get the device and restore the link. In order to do so, NM will automatically generate a "hidden" connection profile and configure it to the wpa_supplicant. It has the exact same properties as 2), but it has a few additional properties: the bssid and the scan_freq. Thanks to that, the supplicant won't spend time scanning. NM must *not* do a full scan either, and then you'll be able to connect in less than 500ms. Note that you connect to profile 2), a known connection profile. Then, NM requests ownership, which removes the RFKILL state, and the supplicant can associate immediately. Had AMT replied to NM that it is connection to MyEmployerEnterpriseNetworkThatNMDoesNotKnow, NM would get to the conclusion that it cannot take the device and AMT will keep the device. There is one thing I didn't mention. AMT will monitor the connection. If it doesn't see an answer to the DHCP request within 3 seconds, it'll take the device back (RFKILL again) to avoid to break the TCP connection. Another thing. When the AMT TCP connection is over, NM will get a notification to say: back to normal. At this point NM can remove the "sub profile" and use the normal profile 2) which will allow to roam etc... So TD;LR: Yes we use connection profiles (we don't pass the security credentials over the new kernel / userspace APIs, so the profile must exist). We just add a new "sub profile" that includes the same parameters, but only 1 AP of that ESSID. Hope this was clearer. > > > > Any recommendation for the implementation? > > NetworkManager does talk relatively little
