Re: DHCP renewal changes routing table
On Thu, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote: > > > When I run the Juniper Network Connect client (ncsvc) it terminates > every time the DHCP license is renewed. The log files of ncsvc are > unfortunately rather cryptic, but it appears as if the DHCP renewal > leads to a change in the routing table which triggers a "rmon.error" > in ncsvc which then tears down the VPN tunnel. Using timestamps the > following two events correlate: FWIW we added support for Juniper Network Connect to the openconnect VPN client in March of last year, a few months before you wrote the above email. In the last week or so we added NetworkManager support for using openconnect with the Juniper protocol too. So you shouldn't really need to run badly-integrated third-party code at all :) I'd be interested to know how well it works for you (and it making it work, if it doesn't). -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP renewal changes routing table
On Fr, 2015-06-05 at 11:39 -0500, Dan Williams wrote: On Thu, 2015-06-04 at 13:45 +0200, Thomas Haller wrote: On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote: Hi, When I run the Juniper Network Connect client (ncsvc) it terminates every time the DHCP license is renewed. The log files of ncsvc are unfortunately rather cryptic, but it appears as if the DHCP renewal leads to a change in the routing table which triggers a rmon.error in ncsvc which then tears down the VPN tunnel. Using timestamps the following two events correlate: 20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to destination 192.168.1.1 is missing mask 255.255.255.255 with gw 0.0.0.0, metric 1, if_id 0, disconnecting (routemon.cpp:628) which coincides with the following journal entries: Jun 03 13:34:55.454967 host NetworkManager[1805]: address 192.168.1.16 Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24 Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300 seconds Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway 192.168.1.1 Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver '192.168.1.1' Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0): DHCPv4 state changed bound - bound Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus -org.freedesktop.nm-dispatcher.service' Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching action 'dhcp4-change' for wlp6s0 Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost carrier Besides the ncsvc error listed above I sometimes also see this one: 20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized new route to 192.168.1.0/0.0.0.0 has been added(conflicts with our route to 0.0.0.0), disconnecting (routemon.cpp:598) Both seem to indicate that the routing table is changed on DHCP renewal. Is there a way to prevent networkmanager from doing this? Or is this problem caused by something else possibly? as you suspect, this is caused by NetworkManager. At various times (e.g. when activating a connection, or on new DHCP lease), NM will reinstall routes. recently there was a related email thread: https://mail.gnome.org/archives/networkmanager-list/2015 -May/msg00016.html but no solution either. We could change NM not only do any system-modification when it will actually have any effect. Like, re-installing a route, only if it is not yet currently there. In NM 1.0.x we still have nm_platform_ip4_route_sync() which already checks array_contains_ip4_route(), so shouldn't that prevent re-installation of device-specific routes that are already there? Or this is only about the default route and subnet routes from the NMDefaultRouteManager? Yes, NMRouteManager would not install routes that are already present. But from DHCP a new address/route could be announced, or another interface might activate/deactivate... http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-route-manager.c?id=d38c3851f803c4e2f6faa1f88dfe55f952148891#n558 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
Re: DHCP renewal changes routing table
On Thu, 2015-06-04 at 13:45 +0200, Thomas Haller wrote: On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote: Hi, When I run the Juniper Network Connect client (ncsvc) it terminates every time the DHCP license is renewed. The log files of ncsvc are unfortunately rather cryptic, but it appears as if the DHCP renewal leads to a change in the routing table which triggers a rmon.error in ncsvc which then tears down the VPN tunnel. Using timestamps the following two events correlate: 20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to destination 192.168.1.1 is missing mask 255.255.255.255 with gw 0.0.0.0, metric 1, if_id 0, disconnecting (routemon.cpp:628) which coincides with the following journal entries: Jun 03 13:34:55.454967 host NetworkManager[1805]: address 192.168.1.16 Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24 Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300 seconds Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway 192.168.1.1 Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver '192.168.1.1' Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0): DHCPv4 state changed bound - bound Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus -org.freedesktop.nm-dispatcher.service' Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching action 'dhcp4-change' for wlp6s0 Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost carrier Besides the ncsvc error listed above I sometimes also see this one: 20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized new route to 192.168.1.0/0.0.0.0 has been added(conflicts with our route to 0.0.0.0), disconnecting (routemon.cpp:598) Both seem to indicate that the routing table is changed on DHCP renewal. Is there a way to prevent networkmanager from doing this? Or is this problem caused by something else possibly? as you suspect, this is caused by NetworkManager. At various times (e.g. when activating a connection, or on new DHCP lease), NM will reinstall routes. recently there was a related email thread: https://mail.gnome.org/archives/networkmanager-list/2015 -May/msg00016.html but no solution either. We could change NM not only do any system-modification when it will actually have any effect. Like, re-installing a route, only if it is not yet currently there. In NM 1.0.x we still have nm_platform_ip4_route_sync() which already checks array_contains_ip4_route(), so shouldn't that prevent re-installation of device-specific routes that are already there? Or this is only about the default route and subnet routes from the NMDefaultRouteManager? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP renewal changes routing table
On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote: Hi, When I run the Juniper Network Connect client (ncsvc) it terminates every time the DHCP license is renewed. The log files of ncsvc are unfortunately rather cryptic, but it appears as if the DHCP renewal leads to a change in the routing table which triggers a rmon.error in ncsvc which then tears down the VPN tunnel. Using timestamps the following two events correlate: 20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to destination 192.168.1.1 is missing mask 255.255.255.255 with gw 0.0.0.0, metric 1, if_id 0, disconnecting (routemon.cpp:628) which coincides with the following journal entries: Jun 03 13:34:55.454967 host NetworkManager[1805]: address 192.168.1.16 Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24 Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300 seconds Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway 192.168.1.1 Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver '192.168.1.1' Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0): DHCPv4 state changed bound - bound Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus -org.freedesktop.nm-dispatcher.service' Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching action 'dhcp4-change' for wlp6s0 Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost carrier Besides the ncsvc error listed above I sometimes also see this one: 20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized new route to 192.168.1.0/0.0.0.0 has been added(conflicts with our route to 0.0.0.0), disconnecting (routemon.cpp:598) Both seem to indicate that the routing table is changed on DHCP renewal. Is there a way to prevent networkmanager from doing this? Or is this problem caused by something else possibly? as you suspect, this is caused by NetworkManager. At various times (e.g. when activating a connection, or on new DHCP lease), NM will reinstall routes. recently there was a related email thread: https://mail.gnome.org/archives/networkmanager-list/2015 -May/msg00016.html but no solution either. We could change NM not only do any system-modification when it will actually have any effect. Like, re-installing a route, only if it is not yet currently there. There was an idea to add a feature to propert routes. https://bugzilla.gnome.org/show_bug.cgi?id=749376 It's not clear how this feature could look like, but probably it should be designed in a way, that you can tell NM ~not to configure~ certain routes. IMO ncsvc should allow you to white-list certain routes, so you could say: don't tear down VPN when somebody messes with 192.168.1.0/24. 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
Re: DHCP renewal changes routing table
Thanks Thomas for the helpful comments. It sounds like that there is no solution at the moment through networkmanager-1.0.2, right? I was naively considering some script in /etc/NetworkManager/dispatcher.d, but from the email threads you link it sounds like as if the routing table update would happen anyway. Thanks again for the help! nick On Thu, Jun 4, 2015 at 5:45 AM, Thomas Haller thal...@redhat.com wrote: On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote: Hi, When I run the Juniper Network Connect client (ncsvc) it terminates every time the DHCP license is renewed. The log files of ncsvc are unfortunately rather cryptic, but it appears as if the DHCP renewal leads to a change in the routing table which triggers a rmon.error in ncsvc which then tears down the VPN tunnel. Using timestamps the following two events correlate: 20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to destination 192.168.1.1 is missing mask 255.255.255.255 with gw 0.0.0.0, metric 1, if_id 0, disconnecting (routemon.cpp:628) which coincides with the following journal entries: Jun 03 13:34:55.454967 host NetworkManager[1805]: address 192.168.1.16 Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24 Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300 seconds Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway 192.168.1.1 Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver '192.168.1.1' Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0): DHCPv4 state changed bound - bound Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus -org.freedesktop.nm-dispatcher.service' Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching action 'dhcp4-change' for wlp6s0 Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost carrier Besides the ncsvc error listed above I sometimes also see this one: 20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized new route to 192.168.1.0/0.0.0.0 has been added(conflicts with our route to 0.0.0.0), disconnecting (routemon.cpp:598) Both seem to indicate that the routing table is changed on DHCP renewal. Is there a way to prevent networkmanager from doing this? Or is this problem caused by something else possibly? as you suspect, this is caused by NetworkManager. At various times (e.g. when activating a connection, or on new DHCP lease), NM will reinstall routes. recently there was a related email thread: https://mail.gnome.org/archives/networkmanager-list/2015 -May/msg00016.html but no solution either. We could change NM not only do any system-modification when it will actually have any effect. Like, re-installing a route, only if it is not yet currently there. There was an idea to add a feature to propert routes. https://bugzilla.gnome.org/show_bug.cgi?id=749376 It's not clear how this feature could look like, but probably it should be designed in a way, that you can tell NM ~not to configure~ certain routes. IMO ncsvc should allow you to white-list certain routes, so you could say: don't tear down VPN when somebody messes with 192.168.1.0/24. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP renewal changes routing table
On Do, 2015-06-04 at 05:56 -0600, Nicolas Bock wrote: Thanks Thomas for the helpful comments. It sounds like that there is no solution at the moment through networkmanager-1.0.2, right? I was naively considering some script in /etc/NetworkManager/dispatcher.d, but from the email threads you link it sounds like as if the routing table update would happen anyway. A dispatcher script would not prevent NM from adding any routes. Maybe using the VPN, you use it together with a connection that either only has static configuration ipv4.method=manual ipv4.addresses=... ipv4.routes=... or that suppresses routes from DHCP ipv4.method=auto ipv4.routes=... ipv4.ignore-auto-routes=yes that might work well enough, but that's not a real solution. Thomas Thanks again for the help! nick On Thu, Jun 4, 2015 at 5:45 AM, Thomas Haller thal...@redhat.com wrote: On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote: Hi, When I run the Juniper Network Connect client (ncsvc) it terminates every time the DHCP license is renewed. The log files of ncsvc are unfortunately rather cryptic, but it appears as if the DHCP renewal leads to a change in the routing table which triggers a rmon.error in ncsvc which then tears down the VPN tunnel. Using timestamps the following two events correlate: 20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to destination 192.168.1.1 is missing mask 255.255.255.255 with gw 0.0.0.0, metric 1, if_id 0, disconnecting (routemon.cpp:628) which coincides with the following journal entries: Jun 03 13:34:55.454967 host NetworkManager[1805]: address 192.168.1.16 Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24 Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300 seconds Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway 192.168.1.1 Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver '192.168.1.1' Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0): DHCPv4 state changed bound - bound Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus -org.freedesktop.nm-dispatcher.service' Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching action 'dhcp4-change' for wlp6s0 Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost carrier Besides the ncsvc error listed above I sometimes also see this one: 20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized new route to 192.168.1.0/0.0.0.0 has been added(conflicts with our route to 0.0.0.0), disconnecting (routemon.cpp:598) Both seem to indicate that the routing table is changed on DHCP renewal. Is there a way to prevent networkmanager from doing this? Or is this problem caused by something else possibly? as you suspect, this is caused by NetworkManager. At various times (e.g. when activating a connection, or on new DHCP lease), NM will reinstall routes. recently there was a related email thread: https://mail.gnome.org/archives/networkmanager-list/2015 -May/msg00016.html but no solution either. We could change NM not only do any system-modification when it will actually have any effect. Like, re-installing a route, only if it is not yet currently there. There was an idea to add a feature to propert routes. https://bugzilla.gnome.org/show_bug.cgi?id=749376 It's not clear how this feature could look like, but probably it should be designed in a way, that you can tell NM ~not to configure~ certain routes. IMO ncsvc should allow you to white-list certain routes, so you could say: don't tear down VPN when somebody messes with 192.168.1.0/24. 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
Re: DHCP renewal changes routing table
On Thu, Jun 4, 2015 at 6:07 AM, Thomas Haller thal...@redhat.com wrote: On Do, 2015-06-04 at 05:56 -0600, Nicolas Bock wrote: Thanks Thomas for the helpful comments. It sounds like that there is no solution at the moment through networkmanager-1.0.2, right? I was naively considering some script in /etc/NetworkManager/dispatcher.d, but from the email threads you link it sounds like as if the routing table update would happen anyway. A dispatcher script would not prevent NM from adding any routes. Maybe using the VPN, you use it together with a connection that either only has static configuration ipv4.method=manual ipv4.addresses=... ipv4.routes=... or that suppresses routes from DHCP ipv4.method=auto ipv4.routes=... ipv4.ignore-auto-routes=yes that might work well enough, but that's not a real solution. Could I do that such that nm uses the normal approach while not using ncsvc, and switches to ignoring routes while under VPN? Thomas Thanks again for the help! nick On Thu, Jun 4, 2015 at 5:45 AM, Thomas Haller thal...@redhat.com wrote: On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote: Hi, When I run the Juniper Network Connect client (ncsvc) it terminates every time the DHCP license is renewed. The log files of ncsvc are unfortunately rather cryptic, but it appears as if the DHCP renewal leads to a change in the routing table which triggers a rmon.error in ncsvc which then tears down the VPN tunnel. Using timestamps the following two events correlate: 20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to destination 192.168.1.1 is missing mask 255.255.255.255 with gw 0.0.0.0, metric 1, if_id 0, disconnecting (routemon.cpp:628) which coincides with the following journal entries: Jun 03 13:34:55.454967 host NetworkManager[1805]: address 192.168.1.16 Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24 Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300 seconds Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway 192.168.1.1 Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver '192.168.1.1' Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0): DHCPv4 state changed bound - bound Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus -org.freedesktop.nm-dispatcher.service' Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching action 'dhcp4-change' for wlp6s0 Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost carrier Besides the ncsvc error listed above I sometimes also see this one: 20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized new route to 192.168.1.0/0.0.0.0 has been added(conflicts with our route to 0.0.0.0), disconnecting (routemon.cpp:598) Both seem to indicate that the routing table is changed on DHCP renewal. Is there a way to prevent networkmanager from doing this? Or is this problem caused by something else possibly? as you suspect, this is caused by NetworkManager. At various times (e.g. when activating a connection, or on new DHCP lease), NM will reinstall routes. recently there was a related email thread: https://mail.gnome.org/archives/networkmanager-list/2015 -May/msg00016.html but no solution either. We could change NM not only do any system-modification when it will actually have any effect. Like, re-installing a route, only if it is not yet currently there. There was an idea to add a feature to propert routes. https://bugzilla.gnome.org/show_bug.cgi?id=749376 It's not clear how this feature could look like, but probably it should be designed in a way, that you can tell NM ~not to configure~ certain routes. IMO ncsvc should allow you to white-list certain routes, so you could say: don't tear down VPN when somebody messes with 192.168.1.0/24. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP renewal changes routing table
On Do, 2015-06-04 at 06:13 -0600, Nicolas Bock wrote: On Thu, Jun 4, 2015 at 6:07 AM, Thomas Haller thal...@redhat.com wrote: On Do, 2015-06-04 at 05:56 -0600, Nicolas Bock wrote: Thanks Thomas for the helpful comments. It sounds like that there is no solution at the moment through networkmanager-1.0.2, right? I was naively considering some script in /etc/NetworkManager/dispatcher.d, but from the email threads you link it sounds like as if the routing table update would happen anyway. A dispatcher script would not prevent NM from adding any routes. Maybe using the VPN, you use it together with a connection that either only has static configuration ipv4.method=manual ipv4.addresses=... ipv4.routes=... or that suppresses routes from DHCP ipv4.method=auto ipv4.routes=... ipv4.ignore-auto-routes=yes that might work well enough, but that's not a real solution. Could I do that such that nm uses the normal approach while not using ncsvc, and switches to ignoring routes while under VPN? you can add a second connections (connections are like profiles). You would still have to activate the right one manually, but maybe combine it with your VPN startup-script... #!/bin/sh nmcli connection up eth0-static-routes ncsvc connect Thomas Thomas Thanks again for the help! nick On Thu, Jun 4, 2015 at 5:45 AM, Thomas Haller thal...@redhat.com wrote: On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote: Hi, When I run the Juniper Network Connect client (ncsvc) it terminates every time the DHCP license is renewed. The log files of ncsvc are unfortunately rather cryptic, but it appears as if the DHCP renewal leads to a change in the routing table which triggers a rmon.error in ncsvc which then tears down the VPN tunnel. Using timestamps the following two events correlate: 20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to destination 192.168.1.1 is missing mask 255.255.255.255 with gw 0.0.0.0, metric 1, if_id 0, disconnecting (routemon.cpp:628) which coincides with the following journal entries: Jun 03 13:34:55.454967 host NetworkManager[1805]: address 192.168.1.16 Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24 Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300 seconds Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway 192.168.1.1 Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver '192.168.1.1' Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0): DHCPv4 state changed bound - bound Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus -org.freedesktop.nm-dispatcher.service' Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching action 'dhcp4-change' for wlp6s0 Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost carrier Besides the ncsvc error listed above I sometimes also see this one: 20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized new route to 192.168.1.0/0.0.0.0 has been added(conflicts with our route to 0.0.0.0), disconnecting (routemon.cpp:598) Both seem to indicate that the routing table is changed on DHCP renewal. Is there a way to prevent networkmanager from doing this? Or is this problem caused by something else possibly? as you suspect, this is caused by NetworkManager. At various times (e.g. when activating a connection, or on new DHCP lease), NM will reinstall routes. recently there was a related email thread: https://mail.gnome.org/archives/networkmanager-list/2015 -May/msg00016.html but no solution either. We could change NM not only do any system-modification when it will actually have any effect. Like, re-installing a route, only if it is not yet currently there. There was an idea to add a feature to propert routes. https://bugzilla.gnome.org/show_bug.cgi?id=749376 It's not clear how this feature could look like, but probably it should be designed in a way, that you can tell NM ~not to configure~ certain routes. IMO ncsvc should allow you to white-list certain routes, so you could say: don't tear down VPN when somebody messes with 192.168.1.0/24. Thomas signature.asc Description: This is a digitally signed message part ___
