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
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
