At 1:26 PM -0500 3/13/07, Mikkel L. Ellertson wrote: >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. That is what I suspect, but I also am not sure. >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. Actually, I don't think I'd need any rules at all for the VM, as it should be able to do its own firewalling -- and it does, I'm fighting with it now (and winning!). >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. FWIW, I have been doing "iptables --flush" and later "iptables-restore", and that doesn't unfilter the tap. I think, since the output of "iptables -vL" says "any" for the interface, that I'd have to make more specific rules. Maybe I'm starting to understand it. -- ____________________________________________________________________ TonyN.:' <mailto:tonynelson@xxxxxxxxxxxxxxxxx> ' <http://www.georgeanelson.com/>
