Hide Forgot
Description of problem: Networkmanager expects tun0 device from libreswan when libreswan (fork of openswan) does not provide any such device. This works fine on rhel6 with openswan, so this issue is regression. Version-Release number of selected component (if applicable): NetworkManager-0.9.9.0-20.git20131108.el7.x86_64 How reproducible: always Steps to Reproduce: 1. configure a vpn with libreswan 2. connect the vpn. 3. Actual results: The logs shows following errors: Nov 13 15:10:59 dhcp129-63 NetworkManager[704]: <info> VPN connection 'jsgnjsmtest' (Connect) reply received. Nov 13 15:11:00 dhcp129-63 NetworkManager[704]: <info> VPN connection 'jsgnjsmtest' (IP4 Config Get) reply received from old-style plugin. Nov 13 15:11:00 dhcp129-63 NetworkManager[704]: <error> [1384373460.3025] [vpn-manager/nm-vpn-connection.c:746] process_generic_config(): (tun0): failed to look up VPN interface index Nov 13 15:11:00 dhcp129-63 NetworkManager[704]: <warn> VPN connection 'jsgnjsmtest' did not receive valid IP config information. Nov 13 15:42:31 dhcp129-63 NetworkManager[704]: <info> VPN connection 'jsgnjsmtest' (Connect) reply received. Nov 13 15:42:32 dhcp129-63 NetworkManager[704]: <info> VPN connection 'jsgnjsmtest' (IP4 Config Get) reply received from old-style plugin. Nov 13 15:42:32 dhcp129-63 NetworkManager[704]: <error> [1384375352.232103] [vpn-manager/nm-vpn-connection.c:738] process_generic_config(): invalid or missing tunnel device received! Nov 13 15:42:32 dhcp129-63 NetworkManager[704]: <warn> VPN connection 'jsgnjsmtest' did not receive valid IP config information. Expected results: NetworkManager should not expect tun0 interface from libreswan. Additional info:
Is this a regression from previous versions of NetworkManager in RHEL7? Is the behavior of upstream Fedora 20 NetworkManager different here than what's in RHEL7?
(In reply to Dan Williams from comment #3) > Is this a regression from previous versions of NetworkManager in RHEL7? Is > the behavior of upstream Fedora 20 NetworkManager different here than what's > in RHEL7? This is a regression from RHEL6. openswan/libreswan do not provide tun0 interface.
There is related issue which has been since f18: https://bugzilla.redhat.com/show_bug.cgi?id=865883
Fixes pushed upstream to dcbw/vpn-no-iface for review. There are one or two other fixes, but this branch enables NetworkManager-openswan with libreswan 3.7 to work with the Red Hat VPN, after disabling the NM-openswan tunnel interface hack.
Avesh; eventually NetworkManager-openswan should simply not pass any tunnel interface at all, instead of the current workarounds. Obviously that's not backwards compatible right now, so in the dcbw/vpn-no-iface branch NetworkManager also recognizes "_none_" as a NULL tunnel interface name. We should continue to use "_none_" until we can switch NM-openswan over to passing no tunnel interface name at all.
(In reply to Dan Williams from comment #7) > Avesh; eventually NetworkManager-openswan should simply not pass any tunnel > interface at all, instead of the current workarounds. Obviously that's not > backwards compatible right now, so in the dcbw/vpn-no-iface branch > NetworkManager also recognizes "_none_" as a NULL tunnel interface name. We > should continue to use "_none_" until we can switch NM-openswan over to > passing no tunnel interface name at all. The latest changes in rhel and fedora pass "none" as tunnel interface. The patch 0007-openswan-libreswan-does-not-provide-tun0-interface-s.patch does this. So NM-openswan seems good w.r.t. this.
(In reply to Dan Williams from comment #6) > Fixes pushed upstream to dcbw/vpn-no-iface for review. >> dns-manager: allow NULL interface name for IP configs We set also the tag IP_CONFIG_IFACE_TAG for NMIP4Config, but it is never used there. also, I would: + g_assert (!g_object_get_data (G_OBJECT (config, IP_CONFIG_IFACE_TAG)); if (iface) g_object_set_data_full (G_OBJECT (config), IP_CONFIG_IFACE_TAG... Appart from that, it looks good to me (I did not test it).
(In reply to Avesh Agarwal from comment #8) > (In reply to Dan Williams from comment #7) > > Avesh; eventually NetworkManager-openswan should simply not pass any tunnel > > interface at all, instead of the current workarounds. Obviously that's not > > backwards compatible right now, so in the dcbw/vpn-no-iface branch > > NetworkManager also recognizes "_none_" as a NULL tunnel interface name. We > > should continue to use "_none_" until we can switch NM-openswan over to > > passing no tunnel interface name at all. > > The latest changes in rhel and fedora pass "none" as tunnel interface. The > patch 0007-openswan-libreswan-does-not-provide-tun0-interface-s.patch does > this. So NM-openswan seems good w.r.t. this. Do the pass "none" or "_none_"? I picked "_none_" because that seems much less likely to ever be an interface name, while "none" technically is valid.
(In reply to Dan Williams from comment #10) > (In reply to Avesh Agarwal from comment #8) > > (In reply to Dan Williams from comment #7) > > > Avesh; eventually NetworkManager-openswan should simply not pass any tunnel > > > interface at all, instead of the current workarounds. Obviously that's not > > > backwards compatible right now, so in the dcbw/vpn-no-iface branch > > > NetworkManager also recognizes "_none_" as a NULL tunnel interface name. We > > > should continue to use "_none_" until we can switch NM-openswan over to > > > passing no tunnel interface name at all. > > > > The latest changes in rhel and fedora pass "none" as tunnel interface. The > > patch 0007-openswan-libreswan-does-not-provide-tun0-interface-s.patch does > > this. So NM-openswan seems good w.r.t. this. > > Do the pass "none" or "_none_"? I picked "_none_" because that seems much > less likely to ever be an interface name, while "none" technically is valid. See below: #define NM_VPN_PLUGIN_IP4_CONFIG_TUNDEV_NONE "_none_" So seems fine as you explained.
(In reply to Thomas Haller from comment #9) > (In reply to Dan Williams from comment #6) > > Fixes pushed upstream to dcbw/vpn-no-iface for review. > > > >> dns-manager: allow NULL interface name for IP configs > > We set also the tag IP_CONFIG_IFACE_TAG for NMIP4Config, but it is never > used there. > > also, I would: > + g_assert (!g_object_get_data (G_OBJECT (config, IP_CONFIG_IFACE_TAG)); > if (iface) > g_object_set_data_full (G_OBJECT (config), IP_CONFIG_IFACE_TAG... > > > > Appart from that, it looks good to me (I did not test it). actually, I think just removing the "if (iface)" should be sufficient, since IP_CONFIG_IFACE_TAG should always follow the 'iface' here. g_strdup(NULL) returns NULL, so that would correctly clear the tag if it was previously set.
upstream dcbw/vpn-no-iface branch merged to git master.
Actually been in RHEL7 builds since 2014-01-27...
connecting via libreswan to vpn works as expected
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.