+++ 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 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 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 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 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 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 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 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 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 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 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.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 on 2012-04-14 14:35:12 EDT ---


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

--- Additional comment from m.a.young.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 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 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 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 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.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 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.