Hello list I have a couple of questions about http://www.shorewall.net/XenMyWay.html 1. Why is the approach described not working with and above kernels 2.6.20? What is not working? 2. Is the configuration of Dom0 with two bridges a "shortcut" for the traffic? That is if the following is valid this would not be necessary (Dom0 has 2 interfaces eth0 and eth1? Phys.switch<----->Dom0-peth0<->Dom0-eth0<->xenbr0<->DomU-eth0-192.168.1.10 ^ ( | shortcut ) |---------------->Dom0-peth1<->Dom0-eth1<->xenbr1<->DomU-eth1-192.168.1.20 I guess the shortcut wouldn''t be a bad idea, but I would like to avoid configuration of shorewall in Dom0 since Dom0 isn''t used for anything. Thanks. -- Med venlig hilsen / Best regards Lars E. D. Jensen ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Lars E. D. Jensen wrote:>I have a couple of questions about http://www.shorewall.net/XenMyWay.html > >1. Why is the approach described not working with and above kernels 2.6.20? >What is not working?The netfilter team made some changes to the way that physdev matching in a bridged environment works to cater for certain other configurations. With SHorewall v4 and the perl compiler it does work with some restrictions.>2. Is the configuration of Dom0 with two bridges a "shortcut" for the >traffic? That is if the following is valid this would not be necessary (Dom0 >has 2 interfaces eth0 and eth1? > >Phys.switch<----->Dom0-peth0<->Dom0-eth0<->xenbr0<->DomU-eth0-192.168.1.10 >^ ( | shortcut ) >|---------------->Dom0-peth1<->Dom0-eth1<->xenbr1<->DomU-eth1-192.168.1.20 > >I guess the shortcut wouldn''t be a bad idea, but I would like to avoid >configuration of shorewall in Dom0 since Dom0 isn''t used for anything.Not sure what you mean here. There should be no way for packets to get between xenbr0 and xenbr1 without being passed by ''something'' - where ''something'' is software running on a domain with connections to both bridges. But your diagram is wrong anyway, traffic doesn''t flow through dom-0 between a physical interface and the bridge - at least not in the conventional networking view, although pethn and xenbrn do appear in dom-0 as they have to ''exist'' somewhere. What you actually have, logical view, is : Phys.switch0<----->peth0<->xenbr0<-+->Dom0-eth0 +->DomU-eth0-192.168.1.10 Phys.switch1<----->peth1<->xenbr1<-+->Dom0-eth1 +->DomU-eth1-192.168.1.20 Notice how there is no direct connection between the two ''networks''. I would not advise plugging both physical network ports into the same switch - that rather defeats the point of having a two-bridge setup and may create you a network loop (which believe me, you do NOT want unless you also use STP to disable some of the links). Phys.switch0 might be your internet connection, and Phys.switch1 your internal network. Assuming that you have two separate networks, then you could run shorewall in bridging mode on dom-0, or in bridging or routing mode in dom-u. That changes your network to (using a bridge in dom-u): Phys.switch0<----->peth0<->xenbr0<-+->Dom0-eth0 +->DomU-eth0-192.168.1.10<-+ <br0> Phys.switch1<----->peth1<->xenbr1<-+->Dom0-eth1 | +->DomU-eth1-192.168.1.20<-+ here, br0 is built inside domu and is not visible to anything else. Adding some more devices might get you to : Phys.switch0<----->peth0<->xenbr0<-+->Dom0-eth0 +->Dom1-eth0-192.168.1.10<-+ <br0> Phys.switch1<----->peth1<->xenbr1<-+->Dom0-eth1 | ^ ^ +->Dom1-eth1-192.168.1.20<-+ | | +->Dom2-eth0-192.168.1.21 | +->PC1 +->Dom3-eth0-192.168.1.22 | +-> PC2 Or a slightly more real world : DSl Modem<-------->peth0<->xenbr0<-+->Dom0-eth0 +->Dom1-eth0-a.b.c.d<------+ <Route/NAT> Phys.switch1<----->peth1<->xenbr1<-+->Dom0-eth1-192.168.1.1 | ^ ^ +->Dom1-eth1-192.168.1.20<-+ | | +->Dom2-eth0-192.168.1.21 | +->PC1 +->Dom3-eth0-192.168.1.22 | +-> PC2 Where you see that only dom-1 has a public address, and although the packets do flow ''through'' dom-0, dom-0 doesn''t have any interface actually configured with an IP address outside of the firewall in dom1 and so ''should'' be fairly safe. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Hello Simon Thank you for the explanation, I greatly appreciate that. Concerning the issue with kernel 2.6.20 and above, do you know the restrictions or is it written somewhere? On 02/08/07 14:08, "Simon Hobson" <linux@thehobsons.co.uk> wrote:> Lars E. D. Jensen wrote: > >> I have a couple of questions about http://www.shorewall.net/XenMyWay.html >> >> 1. Why is the approach described not working with and above kernels 2.6.20? >> What is not working? > > The netfilter team made some changes to the way that physdev matching > in a bridged environment works to cater for certain other > configurations. With SHorewall v4 and the perl compiler it does work > with some restrictions. > >> 2. Is the configuration of Dom0 with two bridges a "shortcut" for the >> traffic? That is if the following is valid this would not be necessary (Dom0 >> has 2 interfaces eth0 and eth1? >> >> Phys.switch<----->Dom0-peth0<->Dom0-eth0<->xenbr0<->DomU-eth0-192.168.1.10 >> ^ ( | shortcut ) >> |---------------->Dom0-peth1<->Dom0-eth1<->xenbr1<->DomU-eth1-192.168.1.20 >> >> I guess the shortcut wouldn''t be a bad idea, but I would like to avoid >> configuration of shorewall in Dom0 since Dom0 isn''t used for anything. > > Not sure what you mean here. There should be no way for packets to > get between xenbr0 and xenbr1 without being passed by ''something'' - > where ''something'' is software running on a domain with connections to > both bridges. But your diagram is wrong anyway, traffic doesn''t flow > through dom-0 between a physical interface and the bridge - at least > not in the conventional networking view, although pethn and xenbrn do > appear in dom-0 as they have to ''exist'' somewhere. > > What you actually have, logical view, is : > > Phys.switch0<----->peth0<->xenbr0<-+->Dom0-eth0 > +->DomU-eth0-192.168.1.10 > > Phys.switch1<----->peth1<->xenbr1<-+->Dom0-eth1 > +->DomU-eth1-192.168.1.20 > > Notice how there is no direct connection between the two ''networks''. > I would not advise plugging both physical network ports into the same > switch - that rather defeats the point of having a two-bridge setup > and may create you a network loop (which believe me, you do NOT want > unless you also use STP to disable some of the links). Phys.switch0 > might be your internet connection, and Phys.switch1 your internal > network. > > > Assuming that you have two separate networks, then you could run > shorewall in bridging mode on dom-0, or in bridging or routing mode > in dom-u. That changes your network to (using a bridge in dom-u): > > Phys.switch0<----->peth0<->xenbr0<-+->Dom0-eth0 > +->DomU-eth0-192.168.1.10<-+ > <br0> > Phys.switch1<----->peth1<->xenbr1<-+->Dom0-eth1 | > +->DomU-eth1-192.168.1.20<-+ > > here, br0 is built inside domu and is not visible to anything else. > > > Adding some more devices might get you to : > > Phys.switch0<----->peth0<->xenbr0<-+->Dom0-eth0 > +->Dom1-eth0-192.168.1.10<-+ > <br0> > Phys.switch1<----->peth1<->xenbr1<-+->Dom0-eth1 | > ^ ^ +->Dom1-eth1-192.168.1.20<-+ > | | +->Dom2-eth0-192.168.1.21 > | +->PC1 +->Dom3-eth0-192.168.1.22 > | > +-> PC2 > > > Or a slightly more real world : > > DSl Modem<-------->peth0<->xenbr0<-+->Dom0-eth0 > +->Dom1-eth0-a.b.c.d<------+ > <Route/NAT> > Phys.switch1<----->peth1<->xenbr1<-+->Dom0-eth1-192.168.1.1 | > ^ ^ +->Dom1-eth1-192.168.1.20<-+ > | | +->Dom2-eth0-192.168.1.21 > | +->PC1 +->Dom3-eth0-192.168.1.22 > | > +-> PC2 > > Where you see that only dom-1 has a public address, and although the > packets do flow ''through'' dom-0, dom-0 doesn''t have any interface > actually configured with an IP address outside of the firewall in > dom1 and so ''should'' be fairly safe. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- Med venlig hilsen / Best regards Lars E. D. Jensen DCmedia Hosting, TYPO3 Development Partner Dronningensgade 23, DK-5000 Odense C Website: http://dcmediahosting.com E-mail: lars@dcmediahosting.com Tlf.: +45 8888 7899 Direkte tlf.: +45 8888 7890 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Lars E. D. Jensen wrote:>Concerning the issue with kernel 2.6.20 and above, do you know the >restrictions or is it written somewhere?From the release notes : http://www.shorewall.net/pub/shorewall/4.0/shorewall-4.0.1/releasenotes.txt c) The old BRIDGING=Yes support has been replaced by new bridge support that uses the reduced ''physdev match'' capabilities found in kernel 2.6.20 and later. This new implementation may be used where it is desired to control traffic through a bridge. The new implementation includes the following features: a) A new "Bridge Port" zone type is defined. Specify ''bport'' or ''bport4'' in the TYPE column of /etc/shorewall/zones. Bridge Port zones should be a sub-zone of a regular ipv4 zone that represents all hosts attached to the bridge. b) A new ''bridge'' option is defined for entries in /etc/shorewall/interfaces. Bridges should have this option specified, even if you don''t want to filter traffic going through the bridge. c) Bridge ports must now be defined in /etc/shorewall/interfaces. The INTERFACE column contains both the bridge name and the port name separated by a colon (e.g., "br0:eth1"). No OPTIONS are allowed for bridge ports. The bridge must be defined before its ports and must have the ''bridge'' option. Bridge Port (BP) zones have a number of limitations: a) Each BP zone may only be associated with ports on a single bridge. b) BP zones may not be associated with interfaces that are not bridge ports. c) You may not have policies or rules where the DEST is a BP zone but the source is not a BP zone. If you need such rules, you must use the BP zone''s parent zone as the DEST zone. Given that I think many (most ?) firewalls using bridging probably have policies of "fw net accept" and "fw loc accept" (ie allow all outbound traffic from the firewall) and only need to filter traffic that is inbound or passing through, then these restrictions probably aren''t an issue for most people. That last restriction essentially says that (for a simple setup with two bridged ethernet ports and a fw zone) you have an implicit "fw all accept" policy and cannot have any rules that say otherwise. It will affect people who are paranoid and like to block outbound traffic by default as well as inbound. IIRC Tom posted something about it''s origins, and I think it was something to do with handling IPSEC traffic correctly - the packet needs to be filtered/handled before the outbound port is known, and the end result is that traffic that originates on the machine (which includes traffic received via an IPSEC tunnel) goes through iptables before the outbound port is known and so no attempt is made to apply physdev rules to this traffic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/