How to setup a bridge using Network Manager

I have build some virtual machines at work, but due to the restrictions on the network unfortunately, functionality was limited (was experimenting with an exchange server an AD). I now have a VPN available, through which I have full access, however, I was only able to configure it in network manager. When I tried to configure it in YAST under DSL, it did not work. It’s a PPTP vpn.

When I activated network manager, the bridge existing for the virtual machines went down. the libvrt connection shows as active in VM manager however the virtual machines have no connectivity and apparently can’t get an ip address from it. (it was set to It defaults to Yesterday, I played a bit in Yast, deactivated networkmanager in an attempt to setup the vpn through the DSL module again. That failed, however when I reactivated network manager and created a new nat in VMmanager the connection worked. Now it doesn’t again. My guess is that it worked because Network manager activated and the yast module also kept running the connection with ifup. I can’t start ifup manually apparently. I have suse 12.3. Anybody has an idea on how I can make network manager work with VMs or at least get the VPN working without network manager?



This is one of those things on my “when I can get some time” list. And, I’m surprised no one seems to have posted a comprehensive solution on the Internet (that I can find).

In my spare time, I’ve accumulated a number of items which would contribute to implementing a solution. I’ve been looking at this for awhile, it has nothing to do with using Network Manager and it has everything to do with Linux Bridge devices.

First, you need to understand that the Linux Bridge device is commonly used for both VPNs and Virtual Networking. These devices are exactly the same objects although used for different purposes… So, a starting point to understanding the fundamentals of what you need to do can be found in the brctl man pages (the CLI utility for manaing bridge devices). Although the bridge device is fundamental, depending on the whims of the network designers you <may> have tun and tap devices connecting to the bridge devices

So, keep that in mind. Although I recommend you study how bridge devices work (it’s fundamental), when you start to apply your new-found knowledge to your specific situation, unless you intend to re-build your existing networking (VPN and/or virtual machine networking), you’ll need to analyze and understand how you’re setup.

Another significant decision you may want to consider at this time (and I’m making some of my own decisions now) is whether you want to implement openvswitch… Consider it as “Linux Bridge devices” on steroids, which provides the same functionality but extended to support numerous new features such as VLAN tagging and virtual network names (which is actually also implemented if you create your bridge devices using libvirt’s vm manager). This decision is momentous and if you decide to implement openvswitch later may require enormous re-configuration of your virtual networking… but if implemented now is a lot of new stuff to learn on top of “basic fundamentals.”

Now, let’s get down to exactly what your issue is.

When any technology sets up networking automatically, they can’t assume any “advanced” or optional network configuration. In fact, every documentation I’ve read describes setting up a Linux bridge device on eth0 likely because it’s the most likely interface used although you can certainly bind a bridge device to wlan0(which I’m doing on my laptop).

Note that for simplicity’s sake, these automatically created bridges are bound directly to a physical interface (likely eth0) because anything else isn’t likely.

But, in your situation, a VPN has been configured using some bridge device (almost certainly called br0).
When you’re connecting using a VPN, access directly to the physical interface is disabled and everything is supposed to connect through the bridge device, so other automatically configured networking llike VM virtual networking will be SOL… and <note> that it would be possibly because of <two> reasons…

This is why properly written apps will know how to connect both with and without a VPN, but some will fail in a VPN.

  • The original automatic setup didn’t assume any other bridge devices existed so would be setup bound to the physical interface
  • The original automatic setup likely assumed it would create the first bridge device so likely named it br0… but note that although bridge devices can be used by multiple apps and technologies, generally they should be <configured> for similar use. I assume that a br0 device configured for a VPN would be configured differently than a br0 device used for virtual networking.

This is where I haven’t taken the next step…
I know that the likely solution for simultaneous VPN and virtual networking should be to “chain” bridge devices and therefor <must> use bridge devices with different names.

Additionally, if your objective is to configure virtual networking access to the Internet/non-Host LAN both within and not using a VPN, you’ll likely need to provide a solution, either providing an easy way to switch between differently configured bridge devices (which can be easy, is one reason why bridge devices exist) or configure switching/routing accordingly.

So, there you have it…
I’ve been pre-occupied with other priorities but if you can take this info and run with it, post your solution in detail.