Re: Confused about bridging, firewall (iptables), and DHCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/>

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux