RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1030068 - NetworkManager expects tun0 device from libreswan
Summary: NetworkManager expects tun0 device from libreswan
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Dan Williams
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 921061 999353
TreeView+ depends on / blocked
 
Reported: 2013-11-13 21:00 UTC by Avesh Agarwal
Modified: 2014-06-18 02:50 UTC (History)
11 users (show)

Fixed In Version: NetworkManager-0.9.9.0-36.git20140127
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 12:41:48 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 721724 0 None None None Never

Description Avesh Agarwal 2013-11-13 21:00:15 UTC 
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:
Comment 3 Dan Williams 2013-11-14 02:32:59 UTC 
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?
Comment 4 Avesh Agarwal 2013-11-14 14:37:14 UTC 
(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.
Comment 5 Avesh Agarwal 2013-11-14 14:44:33 UTC 
There is related issue which has been since f18:

https://bugzilla.redhat.com/show_bug.cgi?id=865883
Comment 6 Dan Williams 2013-12-23 18:26:17 UTC 
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.
Comment 7 Dan Williams 2013-12-23 18:41:58 UTC 
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.
Comment 8 Avesh Agarwal 2013-12-23 19:31:02 UTC 
(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.
Comment 9 Thomas Haller 2014-01-03 22:07:50 UTC 
(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).
Comment 10 Dan Williams 2014-01-06 21:39:56 UTC 
(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.
Comment 11 Avesh Agarwal 2014-01-06 21:43:34 UTC 
(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.
Comment 12 Dan Williams 2014-01-06 21:56:16 UTC 
(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.
Comment 14 Dan Williams 2014-01-24 18:00:52 UTC 
upstream dcbw/vpn-no-iface branch merged to git master.
Comment 15 Dan Williams 2014-02-20 03:38:55 UTC 
Actually been in RHEL7 builds since 2014-01-27...
Comment 17 Vladimir Benes 2014-03-12 14:07:49 UTC 
connecting via libreswan to vpn works as expected
Comment 18 Ludek Smid 2014-06-13 12:41:48 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.