lee <l...@yun.yagibdah.de> wrote: > That seems to suggest using a bridge[1], and I find that very > confusing. I understand that apparently I am supposed to replace my > currently used eth1 by a bride device which uses eth1 and to which I > could add other physical devices like eth0. I don't understand what the > purpose of adding more physical devices would be and what I actually > get when I have such a bridge device and what all that has to do with > a guest.
Ah. Consider a bridge to be a software implementation of a network switch. Currently your networking subsystem refers to eth1, which represents the NIC itself. With a bridge, your networking subsystem would refer to a bridge called br1 (say), and the bridge would connect to your eth1. (The bridge name is completely arbitrary; you could call it eth3 if you really wanted to.) The reason you would use a bridge is because then each of your VMs could also connect to the bridge and therefore to eth1, and your host system and each of the VMs would have separate IP addresses, etc. > It seems to me that having the bridge device in theory would somehow > magically enable me to give the guest an IP address in the same network > as the host is. The guest would become visible to your network as a distinct entity to the host, and could get an address using DHCP (if your network uses this), etc. > That isn't what I want because I want the guest behind the firewall > which is on the host (using shorewall). This is actually two unrelated things that you've squashed together. It is completely possible for the host's firewall to restrict access to a guest, regardless of whether the guest is hidden by the host or it appears as an independent system on your network. If you are going to use bridging, though, you do need to tell shorewall about it. See http://www.shorewall.net/SimpleBridge.html Your VM networking choices are these: 1. Bridge - allows the guest to appear on your network as a separate entity to the host 2. NAT - hides the guest behind your host IP address; you'll need to provide some form of proxying (port forwarding) on your host to allow inbound connections to your guest 3. Internal networking - the guest can communicate only with the host 4. No networking - like it says Chris -- 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/60abi9x6q4....@news.roaima.co.uk
