On Tuesday, September 18, 2012 03:25:45 PM lee wrote: > Chris Davies <chris-use...@roaima.co.uk> writes: > > lee <l...@yun.yagibdah.de> wrote: > >> Yes and when I replace the interface I have now (eth1) with a bridge > >> device (br1), then how do I tell shorewall that the guest is in the dmz > >> (for example)? > > > > You need "bridge" and "routeback" set in your shorewall interfaces file. > > Ok, all the examples in the shorewall documentation I'm seeing say that > I need the "routeback" option with bridge devices. I'm fine with that. > > This option doesn't tell me how to treat the bridge device as two > different interfaces which seem to be needed for shorewall to work. > > All the examples in the shorewall documentation I'm seeing assume that I > would have several interfaces rather than only one. > > > Take a look at http://www.shorewall.net/SimpleBridge.html and > > This example uses two interfaces while I would have only one. > > > http://www.shorewall.net/KVM.html. > > This example isn't really explained. It refers you to [1], which also > requires two interfaces. There is other information linked to it which > brings tunneling/tapping stuff into the setup and doesn't explain > anything about that. The example script it refers to is probably > deprecated: It's 4 years old, and there are already start-scripts for > qemu/kvm in effect in Debian. > > Do I need tunneling/tapping? > > > [1]: http://www.shorewall.net/two-interface.htm > > > I think that the second reference will be particularly useful for you > > - ignore the references to wlan0, and replace "eth0" and "br0" with > > "eth1" and "br1" respectively. > > Well, [2] even says clearly: > > > 1.) "IP addresses are properties of systems, not of interfaces." > > 2.) "All IP addresses configured on firewall interfaces are in the $FW > (fw) zone." > > > Number 2.) is definitely *not* what I want. > > Would I need to create a tunneling/tapping interface for the host and > one for each guest to circumvent 2.)? Would that be safe to do? Would > that be better than using the currently unused physical interface eth0 > instead of the currently used eth1 to make a(n independent) bridge > device? --- I'm probably not going to have more than two guests running > at the same time. > > > [2]: http://www.shorewall.net/two-interface.htm
A bridge device merely connects two or more devices--be they real NICs, TAPs, virtual NICs or some such--at layer 2. On my desktop, I have 3 NICs assigned to 3 bridges, and a fourth bridge without a NIC. I can start KVM sessions tapped into any combination of bridges for testing multi-zone firewalls and other systems. The host creates the bridges and assigns the NICs to them. (I turned off NetworkManager because it always interferes.) I named the bridges in the Smoothwall fashion: RED, GREEN, ORANGE and PURPLE. I anally named the taps similarly (and included the KVM instance #) so I can see what's connected to what. I generate explicit MAC addresses for each virt. NIC so I know which bridge they're connected to; the addr includes the KVM instance # and the virt. NIC number. The script deals with booting from HD, ISO, CD/DVD, USB/flash, etc. Only took about 300 lines of bash script. The only thing I haven't yet figured out how to do remotely is attach and detach USB devices to/from VMs (to perform plug-n-play backups, installs and restores). The result is that every VM is addressable from any LAN and can even have ports forwarded to it from the perimeter F/W. I can daisy-chain firewalls and still forward ports from the perimeter to the innermost system. I can simulate systems connected through single-, double-, and even triple-NATting. I can simulate the public internet by using real addresses on the bridge that has no NIC. So yes, if you want 'real' networking, you'll need bridges and taps. The only drawback is that bridges seem to have limited throughput (I'd expect my quad PhenomII to do better than 90Mb/s); I haven't yet seen GigE speeds from the virtual GigE NICs through to any of the wired GigE LANs, or even across the bridge. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209181613.38416.neal.p.mur...@alum.wpi.edu
