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

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

 



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!

[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