This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 819452 - OpenVPN with tap interface not working with libvirt installed
OpenVPN with tap interface not working with libvirt installed
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
16
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Michael Young
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-07 06:07 EDT by Xela777
Modified: 2012-06-05 18:58 EDT (History)
12 users (show)

See Also:
Fixed In Version: xen-4.1.2-7.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 812421
Environment:
Last Closed: 2012-05-18 06:37:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Xela777 2012-05-07 06:07:09 EDT
+++ This bug was initially created as a clone of Bug #812421 +++

Created attachment 577383 [details]
/var/log/messages of openvpn setup

Description of problem:

When I have Openvpn installed together with libvirt/xen, I cannot get openvpn to work. As far as I can tell, the openvpn connection gets set up correctly, but the tap0 interface is then added to the virbr0 virtual bridge and loses its IP address. This renders the openvpn connection useless. If I uninstall libvirt and Xen, virbr0 is not created and the openvpn tap0 get its IP as it should.

I am unsure if virbr0 is created by libvirt or Xen, I installed and uninstalled them together.

Version-Release number of selected component (if applicable):

openvpn.x86_64                     2.2.2-4.fc17     

How reproducible

Steps to Reproduce:
1. set up OpenVPN with a TAP interface
2. Install libvirt/xen
3. set up openvpn connection
  
Actual results:

tap0 interface is created and added to virbr0 and IP address is removed.

Expected results:

tap0 interface not added to virbr0

OR

tap0 address information moved to virbr0

--- Additional comment from limburgher@gmail.com on 2012-04-13 13:04:58 EDT ---

Does your config file include a --local directive specifying the interface to bind to?

--- Additional comment from Johan@Verrept.eu on 2012-04-13 14:26:13 EDT ---

This is an openvpn client, not a server (it's a development machine).  

I do not believe the --local directive is very useful for a client. As far as I understand, the --local directive is used to bind the SSL tunnel connection while the tap0 interface is only created after the SSL is already established.

The openvpn client config was created by with the gnome network manager.

--- Additional comment from limburgher@gmail.com on 2012-04-13 14:32:00 EDT ---

Ah, I see.  Does it behave the same way if you establish the vpn connection from the commandline?

--- Additional comment from Johan@Verrept.eu on 2012-04-13 15:34:26 EDT ---

Yes, it does. 

I am not so sure this is an actual openvpn problem. It seems like as soon as the tap interface is created, the interface is "hijacked" and added to the bridge. Perhaps the problem is in whatever mechanism is responsible for that?

PS: it is libvirt, not xen.

--- Additional comment from davids@redhat.com on 2012-04-13 15:39:04 EDT ---

If you want a GUI version for openvpn which doesn't do so much magic as NetworkManager-openvpn, consider gopenvpn [1] instead.  NetworkManager-openvpn is not suitable for more advanced setups.  

As this happens when OpenVPN is started from the command line, it must be NetworkManager which does this magic.  It should probably be made possible to make NetworkManager ignore such "ad-hoc" network devices (if that's not possible already).

OpenVPN itself does not modify bridges.  That can only done via script hooks. NetworkManager-openvpn makes OpenVPN use --up /usr/libexec/nm-openvpn-service-openvpn-helper when configuring the VPN interface.  But NetworkManager probably catches that a bridge capable interface is created, and expects that you want that NIC into the bridge as well.  TAP interfaces are bridge capable.

Could you try to use TUN and see what happens?  Either it works or NetworkManager explodes when it fails adding a TUN device to a bridge.  TUN devices cannot be used in bridges at all.



[1] http://gopenvpn.sourceforge.net/

--- Additional comment from Johan@Verrept.eu on 2012-04-13 15:40:49 EDT ---

Created attachment 577403 [details]
Openvpn verbose level 4 output of connection setup

output of:

openvpn --proto tcp-client --tls-client  --ca ca.pem --dev tap --cert machine.pem --key machine_key.pem --remote 192.168.1.2 443 --verb 4

--- Additional comment from davids@redhat.com on 2012-04-13 15:53:21 EDT ---

(In reply to comment #6)
> Created attachment 577403 [details]
> Openvpn verbose level 4 output of connection setup
> 
> output of:
> 
> openvpn --proto tcp-client --tls-client  --ca ca.pem --dev tap --cert
> machine.pem --key machine_key.pem --remote 192.168.1.2 443 --verb 4

This log output just begins to confirm that it's NetworkManager which interferes on TAP devices.  There's nothing here which would make bridge changes at all.

Could you try something like:

 openvpn --proto tcp-client --tls-client  --ca ca.pem --dev tun \
     --cert machine.pem --key machine_key.pem --remote 192.168.1.2 443 --verb 4


You would need to modify your server side too, to use tun too.  Just to see what happens.

--- Additional comment from Johan@Verrept.eu on 2012-04-13 16:04:37 EDT ---


I have no problem with using networkmanager-openvpn, it works and I like the desktop integration.

I have done a bit more investigation and it is indeed only for tapX interfaces, if you start openvpn with --dev-type tap --dev ovpn0, the problem does not happen, the ovpn0 device is never added to the bridge.

--- Additional comment from Johan@Verrept.eu on 2012-04-13 16:18:05 EDT ---

I believe have found the culprit.

in /etc/udev/rules.d/xen-backend.rules there is a rule that says:

SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"

with the vif-setup script pointing to vif-bridge which adds the tap device to the bridge.

So I guess it is udev, not network-manager.

--- Additional comment from davids@redhat.com on 2012-04-13 16:24:39 EDT ---



(In reply to comment #8)
> I have no problem with using networkmanager-openvpn, it works and I like the
> desktop integration.

Sorry, I forgot to remove the paragraph about gopenvpn after seeing you did progress.  I got a mid-air bz collision, which caught your progress.

(In reply to comment #9)
> I believe have found the culprit.
> 
> in /etc/udev/rules.d/xen-backend.rules there is a rule that says:
> 
> SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add",
> RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
> 
> with the vif-setup script pointing to vif-bridge which adds the tap device to
> the bridge.
> 
> So I guess it is udev, not network-manager.

Indeed!  I suspect this file comes from xen-runtime then.  Let's push this bug over to the xen guys.  It's quite nasty that xen should "own" all tap devices this way.

--- Additional comment from m.a.young@durham.ac.uk on 2012-04-14 13:08:47 EDT ---

(In reply to comment #10)
> Indeed!  I suspect this file comes from xen-runtime then.  Let's push this bug
> over to the xen guys.  It's quite nasty that xen should "own" all tap devices
> this way.

I am not sure if there is a good way to make this rule specific to xen, but I think it can be narrowed as xen has tap interfaces of the form tap<number>.<number> so the rule could be
SUBSYSTEM=="net", KERNEL=="tap[0-9]*.[0-9]*", ACTION=="add", RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
if that would help.

--- Additional comment from Johan@Verrept.eu on 2012-04-14 14:35:12 EDT ---


It should probably be KERNEL=="tap[0-9]+.[0-9]+" ?

--- Additional comment from m.a.young@durham.ac.uk on 2012-04-14 15:06:54 EDT ---

(In reply to comment #12)
> It should probably be KERNEL=="tap[0-9]+.[0-9]+" ?

Unfortunately udev isn't doing proper regex; + is (I think) an ordinary character and * matches zero or more characters, so [0-9]* will match 1 10 and 100 but also 1x . It isn't ideal but I think it is the best we can do.

--- Additional comment from Johan@Verrept.eu on 2012-04-15 10:48:20 EDT ---


Sorry, I thought about that shortly after posting. It would have been wrong even if it was regex ;).

I can confirm that the change works for openvpn, I have not tried Xen.

--- Additional comment from updates@fedoraproject.org on 2012-04-15 16:14:26 EDT ---

xen-4.1.2-15.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xen-4.1.2-15.fc17

--- Additional comment from davids@redhat.com on 2012-04-16 03:29:53 EDT ---

Just an idea (probably for a longer term goal) ... but can't libvirt/xen use a different name for these tap devices?  More along the lines of what libvirt/KVM does? (which is 'vnet?').  Then a better targeted udev rule could be managed easier, and you avoid hitting more generic setups.

--- Additional comment from updates@fedoraproject.org on 2012-04-16 17:54:34 EDT ---

Package xen-4.1.2-15.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xen-4.1.2-15.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-5959/xen-4.1.2-15.fc17
then log in and leave karma (feedback).

--- Additional comment from m.a.young@durham.ac.uk on 2012-04-19 18:23:04 EDT ---

(In reply to comment #16)
> Just an idea (probably for a longer term goal) ... but can't libvirt/xen use a
> different name for these tap devices?  More along the lines of what libvirt/KVM
> does? (which is 'vnet?').  Then a better targeted udev rule could be managed
> easier, and you avoid hitting more generic setups.
Upstream xen is now thinking along these lines, and there is a proposal to replace tap with xentap in the upcoming major release.

--- Additional comment from updates@fedoraproject.org on 2012-04-19 23:05:49 EDT ---

xen-4.1.2-15.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 1 David Sommerseth 2012-05-07 06:15:42 EDT
Just to clarify, this issue is found on Fedora 16 as well.  An updated xen package is needed for this version too.
Comment 2 Fedora Update System 2012-05-08 16:01:46 EDT
xen-4.1.2-7.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/xen-4.1.2-7.fc16
Comment 3 Fedora Update System 2012-05-10 10:28:37 EDT
Package xen-4.1.2-7.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xen-4.1.2-7.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-7591/xen-4.1.2-7.fc16
then log in and leave karma (feedback).
Comment 4 Fedora Admin XMLRPC Client 2012-05-15 15:38:29 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Fedora Update System 2012-05-18 06:37:27 EDT
xen-4.1.2-7.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 6 Fedora Update System 2012-05-26 05:10:09 EDT
xen-4.1.2-7.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/xen-4.1.2-7.fc15
Comment 7 Fedora Update System 2012-06-05 18:58:22 EDT
xen-4.1.2-7.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.