I use bridge br0 to link a tun/tap interface and eth0. I do this to give full networking functionality to a QEMU instance running Windows. (Using VDE) The bridge br0 gets its ip address by DCHP from our corporate gateway. The QEMU windows instance gets a separate ip address from the corporate gateway. So, for example, br0 may get ip address 192.168.1.123, and the QEMU windows may get ip address 192.168.1.130. I filter traffic through the bridge. All worked fine until kernel 2.6.20. I have followed the revised bridge instructions. If I manually assign Windows its IP address (in windows control panel, using an address within the range set up in shorewall), all works find, and traffic is correctly filtered. However, if I set Windows up to get its address via DHCP, it always fails. The bridge itself correctly gets an IP address via DHCP. I''ve done the following things to try to troubleshoot this: 1. Set all REJECT rules in the "policy" file to log INFO. Shorewall doesn''t seem to generate a reject log indicating blocking of the DCHP traffic from Windows. 2. Set all rules (in "policy" to the zone set for the firewall to ACCEPT. This did not work. 3. If I set the policy "all all ACCEPT", then windows DHCP does work. I''m stumped. I''d appreciate some help figuring out how to make this work again. I can provide my configuration if that is helpful. Thanks, Phil ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Phil, Please configure your mailer to fold long lines. Each of your paragraphs is actually one long line of text. Thanks Phil DeVries wrote:> I use bridge br0 to link a tun/tap interface and eth0. > I do this to give full networking functionality to a QEMU instance running > Windows. (Using VDE) The bridge br0 gets its ip address by DCHP from our > corporate gateway. The QEMU windows instance gets a separate ip address > from the corporate gateway. So, for example, br0 may get ip address > 192.168.1.123, and the QEMU windows may get ip address 192.168.1.130. > I filter traffic through the bridge. All worked fine until kernel 2.6.20. > > I have followed the revised bridge instructions. If I manually assign Windows > its IP address (in windows control panel, using an address within the > range set up in shorewall), all works find, and traffic is correctly filtered. > However, if I set Windows up to get its address via DHCP, it always fails. > The bridge itself correctly gets an IP address via DHCP. > > I''ve done the following things to try to troubleshoot this: > > 1. Set all REJECT rules in the "policy" file to log INFO. > Shorewall doesn''t seem to generate a reject log indicating blocking > of the DCHP traffic from Windows.> 2. Set all rules (in "policy" to the zone set for the firewall to > ACCEPT. This did not work. > 3. If I set the policy "all all ACCEPT", then windows DHCP does work. > > I''m stumped. I''d appreciate some help figuring out how to make this work > again. I can provide my configuration if that is helpful.This is a limitation in the ''revised bridge'' implementation. DHCP relies on broadcasts that have a source IP address of 0.0.0.0. Try adding that address to the zone that corresponds to the Windows system and see if that helps. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Tom Eastep <teastep@shorewall.net> wrote:> Phil DeVries wrote: > > I use bridge br0 to link a tun/tap interface and eth0. > > I do this to give full networking functionality to a QEMU > > instance running Windows. (Using VDE) The bridge br0 gets > > its ip address by DCHP from our corporate gateway. The QEMU > > windows instance gets a separate ip address from the > > corporate gateway. So, for example, br0 may get ip address > > 192.168.1.123, and the QEMU windows may get ip address > > 192.168.1.130. I filter traffic through the bridge. All > > worked fine until kernel 2.6.20. > > > > I have followed the revised bridge instructions. If I > > manually assign Windows its IP address (in windows control > > panel, using an address within the range set up in > > shorewall), all works find, and traffic is correctly > > filtered. However, if I set Windows up to get its address via > > DHCP, it always fails. The bridge itself correctly gets an IP > > address via DHCP. > > > > I''ve done the following things to try to troubleshoot this: > > > > 1. Set all REJECT rules in the "policy" file to log > > INFO. Shorewall doesn''t seem to generate a reject log > > indicating blocking of the DCHP traffic from Windows. > > > 2. Set all rules (in "policy" to the zone set for the > > firewall to ACCEPT. This did not work. > > 3. If I set the policy "all all ACCEPT", then windows > > DHCP does work. > > > > I''m stumped. I''d appreciate some help figuring out how to > > make this work again. I can provide my configuration if that > > is helpful. > > This is a limitation in the ''revised bridge'' implementation. > DHCP relies on broadcasts that have a source IP address of > 0.0.0.0. > > Try adding that address to the zone that corresponds to the > Windows system and see if that helps.I revised my "Hosts" file from brloc br0:192.168.1.130-192.168.1.254 routeback,nosmurfs to brloc br0:192.168.1.130-192.168.1.254,0.0.0.0 routeback,nosmurfs. This did not work. Also, this did not prevent the linux os from getting an ip address from DHCP, which is what I expected. Is there another limitation here too? I presume there''s no way to guarantee that a DHCP server will grant me an address inside the range for brloc. What happens if DHCP tries to give Windows an address outside that range? Phil ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Phil DeVries wrote:>> >> Try adding that address to the zone that corresponds to the >> Windows system and see if that helps. > > I revised my "Hosts" file from > > brloc br0:192.168.1.130-192.168.1.254 routeback,nosmurfs > > to > > brloc br0:192.168.1.130-192.168.1.254,0.0.0.0 routeback,nosmurfs. > > This did not work.What does that mean? - Shorewall didn''t start? - Your firewall erupted in flames? ???> Also, this did not prevent the linux os from > getting an ip address from DHCP, which is what I expected.I didn''t expect that side effect. The Linux OS broadcast is $FW-><whatever>; why would that be affected by the definition of brloc? If you want to pursue this, I''ll need the output of "shorewall dump" collected as described at http://www.shorewall.net/support.htm# Guidelines.> > Is there another limitation here too? I presume there''s no way > to guarantee that a DHCP server will grant me an address inside > the range for brloc. What happens if DHCP tries to give Windows > an address outside that range?Let''s cut to the chase. Dynamic addresses are never going to work correctly with the bridge technique described at http://www.shorewall.net/NewBridge.html. Shorewall-perl has a new implementation of bridge support that uses the reduced-function physdev match support in 2.6.20 and later kernels. Shorewall 4.0.0 Beta 4 will work with kernel 2.6.20; you will have to wait until Beta 5 for complete support for 2.6.21. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/