Bug 1030068

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.