Tony Nelson wrote: > I'm trying to set up a bridge network with qemu, in order to test a web > server running in a sandbox. This is about bridging and firewalling on > Fedora Core 6, and qemu and CentOS in it are working fine. > > After 3 days of struggle, I seem to have the qemu network connection > working, and now I have some mostly sensible questions. (Note that a > server can't use qemu's default user mode network, which behaves like NAT > and blocks all incoming connections.) > > [ I could have figured this much out sooner if I hadn't made some > mistakes, from being new to server administration: > > The CenOS server would mention failing to get its old user mode > network address of 10.0.2.2. When I finally looked in > /var/log/messages I figured out what it was up to. > > I had looked at the iptables rules with "iptables --list" and it > seemed to me that the rules were allowing all traffic. I had > forgotten that iptables' output is useless without the verbose > option, "iptables -v --list", which shows the link to which each > rule applies, and also how many times each rule has been used. > > I didn't remember to "tcpdump -i tap0" to see what was actually > being sent. > ] > > Other than the fact that the computer I'm bridging onto my network is > virtual, I don't think qemu is part of the problem (or rather, after 3 days > of struggle I've made it past the 2.6.18+ kernel CAP_NET_ADMIN issue in the > tun driver, and also past iptables). If it were a real computer, I'd just > plug it into my switch, outside the iptables firewall. I want the same > effect with bridging. > > 1) In order to get DHCP working for tap0 (and qemu), I had to add a rule to > iptables. Possibly my rule is not quite correct, or possibly it is > entirely the wrong rule. This seems to work OK: > > iptables -I RH-Firewall-1-INPUT -p udp --sport 67:68 --dport 67-68 -j ACCEPT > > (Man iptables doens't really explain --dport or --sport, or --port. > Googling indicates that I should need both ports 67 and 68.) > > Maybe what I really want is to allow all traffic between tap0 and eth0 > while firewalling my computer from it, but I don't know if that is how > iptables works. Perhaps something like: > > iptables -I RH-Firewall-1-INPUT tap+ -j ACCEPT > > Probably not. I do need to protect my computer from the server (don't ask). > > > 2) What I'm confident that I don't underestand is the architecture of my > bridge, and where the iptables firewall hooks in. If it's just the > original setup, no bridge, there are rules for the lo and eth0 interfaces, > it "just works", and I realize I don't even understand that. With the > bridge active, where does iptables (or the host computer) fit in? The > bridge looks like: > > eth0 (ip 0.0.0.0) > br0 (ip thru dhcp) > tap0 (ip 0.0.0.0) > lo > computer > qemu > iptables > > I didn't draw any connections because that's what I don't understand. Is it: > > eth0 <-> br0 <-> tap0 <-> qemu > ^ > | > v > iptables <-> lo > ^ > | > v > computer > > Probably not. Is it: > > eth0 <-> iptables <-> br0 <-> iptables <-> tap0 <-> qemu > ^ > | > v > computer <-> iptables <-> lo > > Probably not. > > I've been looking around at man pages, googling on bridging, and I don't > seem to have a clue. I know about TCP/IP and such, and I'm willing to read > some more if I knew what. I am not sure, but I believe the correct way to do it would be to change the iptable rules to use br0 instead of eth0. That way, the real machine and the virtual machine would each have their own firewall. You would then create what ever firewall rules you with on your virtual machine using the tap0 interface, just like you would using eth0 if it were a stand-alone machine. You may have to add rules to set the defaults on eth0 to accept in order to purge the old rules. One thing you could try after the bridge is up is to run "service iptables restart". This might reset the firewall rules to use br0 instead of eth0. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
