Hi I''ve used shorewall now for a few years with on my file server, and have recently added an extra NIC (two nics, eth0 is inward facing to a LAN switch, 192.168.1.3, and eth1 faces the router, 192.168.1.2, in the DomO). I''ve started two XEN virtual DomU machines using the instructions under [1], slimserv.home.xx on eth2 192.168.1.5 and work.home.xx on eth3 192.168.1.6. There is a slimdev on 192.168.1.4 attached to the (wireless) router (192.168.1.1 with dhcp server, default gateway) which should communicate with slimserv. Despite having allowed pings all round in /etc/shorewall/rules (except from net) I am unable to reach any of the machines within the file server (.1.2) or from outside or in the LAN. All machines have the netmask 255.255.255.0. The network is cut in half (each side of the file server), and the LAN zones can''t communicate with each other. Without the shorewall firewall up, I can ping out of the box and _to_ the DomU''s but not _out_ of them. I suspect a routing problem. Can someone help with any ideas? I''ve followed the troubleshooting guide and enclose dump file and show log. The firewall is up (this is causing the problem) and compiled OK. Many thanks for any help! Regards Mark [1] http://www.shorewall.net/XenMyWay-Routed.html ------------------------------------------------------------------------- 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/
On Thu, 2007-08-23 at 16:50 +0200, Mark Furner wrote:> Hi > > I''ve used shorewall now for a few years with on my file server, and have > recently added an extra NIC (two nics, eth0 is inward facing to a LAN switch, > 192.168.1.3, and eth1 faces the router, 192.168.1.2, in the DomO). I''ve > started two XEN virtual DomU machines using the instructions under [1], > slimserv.home.xx on eth2 192.168.1.5 and work.home.xx on eth3 192.168.1.6. > There is a slimdev on 192.168.1.4 attached to the (wireless) router > (192.168.1.1 with dhcp server, default gateway) which should communicate with > slimserv. > > Despite having allowed pings all round in /etc/shorewall/rules (except from > net) I am unable to reach any of the machines within the file server (.1.2) > or from outside or in the LAN. All machines have the netmask 255.255.255.0. > The network is cut in half (each side of the file server), and the LAN zones > can''t communicate with each other. Without the shorewall firewall up, I can > ping out of the box and _to_ the DomU''s but not _out_ of them. I suspect a > routing problem. Can someone help with any ideas? >A few minutes with your log and Shorewall FAQ 17 would have uncovered the problem. You apparently haven''t mentioned eth1 in your Shorewall configuration at all. So it should be no surprise that traffic to/from that interface is blocked when Shorewall is started. -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: 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/
On Thu, 2007-08-23 at 07:58 -0700, Tom Eastep wrote:> On Thu, 2007-08-23 at 16:50 +0200, Mark Furner wrote: > > Hi > > > > I''ve used shorewall now for a few years with on my file server, and have > > recently added an extra NIC (two nics, eth0 is inward facing to a LAN switch, > > 192.168.1.3, and eth1 faces the router, 192.168.1.2, in the DomO). I''ve > > started two XEN virtual DomU machines using the instructions under [1], > > slimserv.home.xx on eth2 192.168.1.5 and work.home.xx on eth3 192.168.1.6. > > There is a slimdev on 192.168.1.4 attached to the (wireless) router > > (192.168.1.1 with dhcp server, default gateway) which should communicate with > > slimserv. > > > > Despite having allowed pings all round in /etc/shorewall/rules (except from > > net) I am unable to reach any of the machines within the file server (.1.2) > > or from outside or in the LAN. All machines have the netmask 255.255.255.0. > > The network is cut in half (each side of the file server), and the LAN zones > > can''t communicate with each other. Without the shorewall firewall up, I can > > ping out of the box and _to_ the DomU''s but not _out_ of them. I suspect a > > routing problem. Can someone help with any ideas? > > > > A few minutes with your log and Shorewall FAQ 17 would have uncovered > the problem. > > You apparently haven''t mentioned eth1 in your Shorewall configuration at > all. So it should be no surprise that traffic to/from that interface is > blocked when Shorewall is started.I also notice that your IP configuration is decidedly odd/broken. You have 10: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:41:1d:02:13 brd ff:ff:ff:ff:ff:ff inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1 inet6 fe80::20c:41ff:fe1d:213/64 scope link valid_lft forever preferred_lft forever 11: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:1b:bb:3a:88 brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0 inet6 fe80::230:1bff:febb:3a88/64 scope link valid_lft forever preferred_lft forever 13: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff inet 192.168.1.5/24 brd 192.168.1.255 scope global eth2 inet6 fe80::fcff:ffff:feff:ffff/64 scope link valid_lft forever preferred_lft forever 14: eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff inet 192.168.1.6/24 brd 192.168.1.255 scope global eth3 inet6 fe80::fcff:ffff:feff:ffff/64 scope link valid_lft forever preferred_lft forever So you have four interfaces, all with addresses in 192.168.1.0/24. The routing configuration: 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.2 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.5 192.168.1.0/24 dev eth3 proto kernel scope link src 192.168.1.6 So all traffic to ANY non-local address in 192.168.1.0/24 is going to be sent via eth1. If these interfaces connect to four different LAN segments, this configuration will never work. If they are connected to the same LAN segment, then why??? -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: 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/
Tom Thanks for the prompt reply. I need to put eth1 into the right conf file... The routing table is probably correct, though. I have a file server connected to a wireless router and default gateway on side, and the LAN on * eth1 is a real ethernet card connecting the file server to the router, where there is one other computer connected, maybe later one or two more, and the wireless. * eth0 is a built-in card that connects the server to the LAN switch, from which other traffic in the loc zone should get to the Internet. * The others are virtual interfaces renamed by xen in the same box and are assigned a DomU each. So, from this firewall, all traffic should go out via eth1. Does that make sense? On Thursday 23 August 2007 17:09, Tom Eastep (Tom Eastep <teastep@shorewall.net>) may have written:> On Thu, 2007-08-23 at 07:58 -0700, Tom Eastep wrote: > > On Thu, 2007-08-23 at 16:50 +0200, Mark Furner wrote: > > > Hi > > > > > > I''ve used shorewall now for a few years with on my file server, and > > > have recently added an extra NIC (two nics, eth0 is inward facing to a > > > LAN switch, 192.168.1.3, and eth1 faces the router, 192.168.1.2, in the > > > DomO). I''ve started two XEN virtual DomU machines using the > > > instructions under [1], slimserv.home.xx on eth2 192.168.1.5 and > > > work.home.xx on eth3 192.168.1.6. There is a slimdev on 192.168.1.4 > > > attached to the (wireless) router (192.168.1.1 with dhcp server, > > > default gateway) which should communicate with slimserv. > > > > > > Despite having allowed pings all round in /etc/shorewall/rules (except > > > from net) I am unable to reach any of the machines within the file > > > server (.1.2) or from outside or in the LAN. All machines have the > > > netmask 255.255.255.0. The network is cut in half (each side of the > > > file server), and the LAN zones can''t communicate with each other. > > > Without the shorewall firewall up, I can ping out of the box and _to_ > > > the DomU''s but not _out_ of them. I suspect a routing problem. Can > > > someone help with any ideas? > > > > A few minutes with your log and Shorewall FAQ 17 would have uncovered > > the problem. > > > > You apparently haven''t mentioned eth1 in your Shorewall configuration at > > all. So it should be no surprise that traffic to/from that interface is > > blocked when Shorewall is started. > > I also notice that your IP configuration is decidedly odd/broken. You > have > > 10: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen > 1000 link/ether 00:0c:41:1d:02:13 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1 > inet6 fe80::20c:41ff:fe1d:213/64 scope link > valid_lft forever preferred_lft forever > 11: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen > 1000 link/ether 00:30:1b:bb:3a:88 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0 > inet6 fe80::230:1bff:febb:3a88/64 scope link > valid_lft forever preferred_lft forever > 13: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue > link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff > inet 192.168.1.5/24 brd 192.168.1.255 scope global eth2 > inet6 fe80::fcff:ffff:feff:ffff/64 scope link > valid_lft forever preferred_lft forever > 14: eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue > link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff > inet 192.168.1.6/24 brd 192.168.1.255 scope global eth3 > inet6 fe80::fcff:ffff:feff:ffff/64 scope link > valid_lft forever preferred_lft forever > > So you have four interfaces, all with addresses in 192.168.1.0/24. > > The routing configuration: > > 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.2 > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 > 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.5 > 192.168.1.0/24 dev eth3 proto kernel scope link src 192.168.1.6 > > So all traffic to ANY non-local address in 192.168.1.0/24 is going to be > sent via eth1. > > If these interfaces connect to four different LAN segments, this > configuration will never work. If they are connected to the same LAN > segment, then why??? > > -Tom------------------------------------------------------------------------- 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/
On Thu, 2007-08-23 at 19:05 +0200, Mark Furner wrote:> Tom > > Thanks for the prompt reply. I need to put eth1 into the right conf file... > > The routing table is probably correct, though. I have a file server connected > to a wireless router and default gateway on side, and the LAN on > > * eth1 is a real ethernet card connecting the file server to the router, where > there is one other computer connected, maybe later one or two more, and the > wireless. > * eth0 is a built-in card that connects the server to the LAN switch, from > which other traffic in the loc zone should get to the Internet. > * The others are virtual interfaces renamed by xen in the same box and are > assigned a DomU each. > So, from this firewall, all traffic should go out via eth1. Does that make > sense?No. The IP configuration on your firewall makes no sense to me whatsoever. -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: 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/
Philipp Rusch
2007-Aug-23 18:18 UTC
Re: shorewall 3.2.6 with xen: possible routing problem
Mark Furner schrieb:> Tom > > Thanks for the prompt reply. I need to put eth1 into the right conf file... > > The routing table is probably correct, though. I have a file server connected > to a wireless router and default gateway on side, and the LAN on > > * eth1 is a real ethernet card connecting the file server to the router, where > there is one other computer connected, maybe later one or two more, and the > wireless. > * eth0 is a built-in card that connects the server to the LAN switch, from > which other traffic in the loc zone should get to the Internet. > * The others are virtual interfaces renamed by xen in the same box and are > assigned a DomU each. > So, from this firewall, all traffic should go out via eth1. Does that make > sense? > > On Thursday 23 August 2007 17:09, Tom Eastep (Tom Eastep > <teastep@shorewall.net>) may have written: > >> On Thu, 2007-08-23 at 07:58 -0700, Tom Eastep wrote: >> >>> On Thu, 2007-08-23 at 16:50 +0200, Mark Furner wrote: >>> >>>> Hi >>>> >>>> I''ve used shorewall now for a few years with on my file server, and >>>> have recently added an extra NIC (two nics, eth0 is inward facing to a >>>> LAN switch, 192.168.1.3, and eth1 faces the router, 192.168.1.2, in the >>>> DomO). I''ve started two XEN virtual DomU machines using the >>>> instructions under [1], slimserv.home.xx on eth2 192.168.1.5 and >>>> work.home.xx on eth3 192.168.1.6. There is a slimdev on 192.168.1.4 >>>> attached to the (wireless) router (192.168.1.1 with dhcp server, >>>> default gateway) which should communicate with slimserv. >>>> >>>> Despite having allowed pings all round in /etc/shorewall/rules (except >>>> from net) I am unable to reach any of the machines within the file >>>> server (.1.2) or from outside or in the LAN. All machines have the >>>> netmask 255.255.255.0. The network is cut in half (each side of the >>>> file server), and the LAN zones can''t communicate with each other. >>>> Without the shorewall firewall up, I can ping out of the box and _to_ >>>> the DomU''s but not _out_ of them. I suspect a routing problem. Can >>>> someone help with any ideas? >>>> >>> A few minutes with your log and Shorewall FAQ 17 would have uncovered >>> the problem. >>> >>> You apparently haven''t mentioned eth1 in your Shorewall configuration at >>> all. So it should be no surprise that traffic to/from that interface is >>> blocked when Shorewall is started. >>> >> I also notice that your IP configuration is decidedly odd/broken. You >> have >> >> 10: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen >> 1000 link/ether 00:0c:41:1d:02:13 brd ff:ff:ff:ff:ff:ff >> inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1 >> inet6 fe80::20c:41ff:fe1d:213/64 scope link >> valid_lft forever preferred_lft forever >> 11: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen >> 1000 link/ether 00:30:1b:bb:3a:88 brd ff:ff:ff:ff:ff:ff >> inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0 >> inet6 fe80::230:1bff:febb:3a88/64 scope link >> valid_lft forever preferred_lft forever >> 13: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue >> link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff >> inet 192.168.1.5/24 brd 192.168.1.255 scope global eth2 >> inet6 fe80::fcff:ffff:feff:ffff/64 scope link >> valid_lft forever preferred_lft forever >> 14: eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue >> link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff >> inet 192.168.1.6/24 brd 192.168.1.255 scope global eth3 >> inet6 fe80::fcff:ffff:feff:ffff/64 scope link >> valid_lft forever preferred_lft forever >> >> So you have four interfaces, all with addresses in 192.168.1.0/24. >> >> The routing configuration: >> >> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.2 >> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 >> 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.5 >> 192.168.1.0/24 dev eth3 proto kernel scope link src 192.168.1.6 >> >> So all traffic to ANY non-local address in 192.168.1.0/24 is going to be >> sent via eth1. >> >> If these interfaces connect to four different LAN segments, this >> configuration will never work. If they are connected to the same LAN >> segment, then why??? >> >> -Tom >>Mark, are you afraid of using too much IP addresses ? You can use as much private nets as you want, as long as you are behind a NAT-Router .... That said I would choose a setup like: eth0: 192.168.1.1 /24 eth1: 192.168.2.1 /24 eth2: 192.168.3.1 /24 eth3: 192.168.4.1 /24 Despite the fact you you have a firewall on the machine that connects all these different nets together, you *must* setup correct routing *if* you want to see hosts on another net. Don''t put ip-adresses of the same net onto different interfaces *unless* you want to do some kind of load-balancing or redundant setup for high-availability. Just my 2 cents. Philipp ------------------------------------------------------------------------- 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/
Vielen Dank Philipp yes, I guessed 252 or so IP addresses are enough. If it is easier to set up I suppose I could use subnets and increase subnet mask to 255.255.0.0. Mark On Thursday 23 August 2007 20:18, Philipp Rusch (Philipp Rusch <philipp.rusch@newvision-it.de>) may have written:> Mark Furner schrieb: > > Tom > > > > Thanks for the prompt reply. I need to put eth1 into the right conf > > file... > > > > The routing table is probably correct, though. I have a file server > > connected to a wireless router and default gateway on side, and the LAN > > on > > > > * eth1 is a real ethernet card connecting the file server to the router, > > where there is one other computer connected, maybe later one or two more, > > and the wireless. > > * eth0 is a built-in card that connects the server to the LAN switch, > > from which other traffic in the loc zone should get to the Internet. > > * The others are virtual interfaces renamed by xen in the same box and > > are assigned a DomU each. > > So, from this firewall, all traffic should go out via eth1. Does that > > make sense? > > > > On Thursday 23 August 2007 17:09, Tom Eastep (Tom Eastep > > > > <teastep@shorewall.net>) may have written: > >> On Thu, 2007-08-23 at 07:58 -0700, Tom Eastep wrote: > >>> On Thu, 2007-08-23 at 16:50 +0200, Mark Furner wrote: > >>>> Hi > >>>> > >>>> I''ve used shorewall now for a few years with on my file server, and > >>>> have recently added an extra NIC (two nics, eth0 is inward facing to a > >>>> LAN switch, 192.168.1.3, and eth1 faces the router, 192.168.1.2, in > >>>> the DomO). I''ve started two XEN virtual DomU machines using the > >>>> instructions under [1], slimserv.home.xx on eth2 192.168.1.5 and > >>>> work.home.xx on eth3 192.168.1.6. There is a slimdev on 192.168.1.4 > >>>> attached to the (wireless) router (192.168.1.1 with dhcp server, > >>>> default gateway) which should communicate with slimserv. > >>>> > >>>> Despite having allowed pings all round in /etc/shorewall/rules (except > >>>> from net) I am unable to reach any of the machines within the file > >>>> server (.1.2) or from outside or in the LAN. All machines have the > >>>> netmask 255.255.255.0. The network is cut in half (each side of the > >>>> file server), and the LAN zones can''t communicate with each other. > >>>> Without the shorewall firewall up, I can ping out of the box and _to_ > >>>> the DomU''s but not _out_ of them. I suspect a routing problem. Can > >>>> someone help with any ideas? > >>> > >>> A few minutes with your log and Shorewall FAQ 17 would have uncovered > >>> the problem. > >>> > >>> You apparently haven''t mentioned eth1 in your Shorewall configuration > >>> at all. So it should be no surprise that traffic to/from that interface > >>> is blocked when Shorewall is started. > >> > >> I also notice that your IP configuration is decidedly odd/broken. You > >> have > >> > >> 10: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen > >> 1000 link/ether 00:0c:41:1d:02:13 brd ff:ff:ff:ff:ff:ff > >> inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1 > >> inet6 fe80::20c:41ff:fe1d:213/64 scope link > >> valid_lft forever preferred_lft forever > >> 11: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen > >> 1000 link/ether 00:30:1b:bb:3a:88 brd ff:ff:ff:ff:ff:ff > >> inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0 > >> inet6 fe80::230:1bff:febb:3a88/64 scope link > >> valid_lft forever preferred_lft forever > >> 13: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue > >> link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff > >> inet 192.168.1.5/24 brd 192.168.1.255 scope global eth2 > >> inet6 fe80::fcff:ffff:feff:ffff/64 scope link > >> valid_lft forever preferred_lft forever > >> 14: eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue > >> link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff > >> inet 192.168.1.6/24 brd 192.168.1.255 scope global eth3 > >> inet6 fe80::fcff:ffff:feff:ffff/64 scope link > >> valid_lft forever preferred_lft forever > >> > >> So you have four interfaces, all with addresses in 192.168.1.0/24. > >> > >> The routing configuration: > >> > >> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.2 > >> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 > >> 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.5 > >> 192.168.1.0/24 dev eth3 proto kernel scope link src 192.168.1.6 > >> > >> So all traffic to ANY non-local address in 192.168.1.0/24 is going to be > >> sent via eth1. > >> > >> If these interfaces connect to four different LAN segments, this > >> configuration will never work. If they are connected to the same LAN > >> segment, then why??? > >> > >> -Tom > > Mark, > > are you afraid of using too much IP addresses ? You can use as much > private nets as you want, > as long as you are behind a NAT-Router .... > That said I would choose a setup like: > > eth0: 192.168.1.1 /24 > eth1: 192.168.2.1 /24 > eth2: 192.168.3.1 /24 > eth3: 192.168.4.1 /24 > > Despite the fact you you have a firewall on the machine that connects > all these different nets > together, you *must* setup correct routing *if* you want to see hosts on > another net. > Don''t put ip-adresses of the same net onto different interfaces *unless* > you want to do > some kind of load-balancing or redundant setup for high-availability. > > Just my 2 cents. > > Philipp------------------------------------------------------------------------- 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/
Andrew Suffield
2007-Aug-23 19:25 UTC
Re: shorewall 3.2.6 with xen: possible routing problem
On Thu, Aug 23, 2007 at 08:34:38PM +0200, Mark Furner wrote:> Vielen Dank Philipp > > yes, I guessed 252 or so IP addresses are enough. If it is easier to set up I > suppose I could use subnets and increase subnet mask to 255.255.0.0.<gibber> Please seek instruction on the concept of network masks and IP routing. Your understanding is flawed beyond the scope of this mailing list. ------------------------------------------------------------------------- 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/
Thanks for taking the time Tom and Philipp, it''s clearer now.> Based on the address, the appropriate interface can be selected; that is > impossible in your routing configuration.I''ll do some more RTFM. Regards Mark On Thursday 23 August 2007 20:56, Tom Eastep <teastep@shorewall.net> may have written:> On Thu, 2007-08-23 at 20:29 +0200, Mark Furner wrote: > > Hmm > > > > Sorry. I''m trying to bind some xen virtual machines on my server in the > > manner you describe in [1] but with less external machines and subnets > > involved. > > > > * One local zone spanning both real NICs eth0 and eth1, which are shared > > by the DomUs. (IP range static: 192.168.1.2-10) > > ... > > * A VPN server listening on eth1 in Dom0 has its own zone, IP range > > also set to within the same subnet. (192.168.1.55-60) > > No! > > If you are going to partition the 192.168.1.0/24 network by interface > you have to do proper subnetting based on powers of two. You can''t break > it up into partitions based on the total number of fingers that humans > have (which is the basis for our millenniums-old love affair with > base-10). > > What Phillip is suggesting is that you use different /24 IP networks for > each interface (not switch from a one /24 to one /16). Compare what you > are doing with my firewall (output abbreviated for clarity): > > 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000 > link/ether 00:19:21:d0:61:65 brd ff:ff:ff:ff:ff:ff > inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0 > ------------------ > inet6 fe80::219:21ff:fed0:6165/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:02:e3:08:55:fa brd ff:ff:ff:ff:ff:ff > inet 192.168.3.254/24 brd 192.168.3.255 scope global eth1 > ---------------- > inet6 fe80::202:e3ff:fe08:55fa/64 scope link > valid_lft forever preferred_lft forever > 6: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue > link/ether 00:a0:cc:db:31:c4 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.254/24 brd 192.168.1.255 scope global br0 > ---------------- > inet6 fe80::2a0:ccff:fedb:31c4/64 scope link > valid_lft forever preferred_lft forever > 8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qdisc pfifo_fast > qlen 100 link/[65534] > inet 192.168.2.1 peer 192.168.2.2/32 scope global tun0 > ----------- > 9: eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue > link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff > inet 206.124.146.176/32 brd 206.124.146.255 scope global eth3 > ------------------ > inet6 fe80::fcff:ffff:feff:ffff/64 scope link > valid_lft forever preferred_lft forever > > Notice that each interface (with the exception of tun0 and the > Xen-renamed ''eth3'') is a different RFC 1918 network. In your > configuration, they are all the same network! > > My eth3 is configured as a single address (/32) -- your Xen VIFs > are /24s and are the same /24 as all of the other interfaces. > > Here''s my Routing table (Annotated and abbreviated for clarity) > > 206.124.146.177 dev eth3 scope link src 206.124.146.176 > <====== Xen DomU 192.168.2.2 dev tun0 proto kernel scope link src > 192.168.2.1 <====== Routed OpenVPN Clients 192.168.3.0/24 dev > eth1 proto kernel scope link src 192.168.3.254 <====== Wifi > 192.168.2.0/24 via 192.168.2.2 dev tun0 > <====== Peer on OpenVPN perm interface tun0 192.168.1.0/24 dev br0 proto > kernel scope link src 192.168.1.254 <====== Local LAN and > 206.124.146.0/24 dev eth0 proto kernel scope link src 206.124.146.176 > <====== External Network default via 206.124.146.254 dev eth0 > <====== Default route via ISP''s router > > Based on the address, the appropriate interface can be selected; that is > impossible in your routing configuration. > > Phillip was trying to encourage you to do the same thing. If you need to > do more reading about subnetting and routing, there is a brief treatment > of the subject in the Shorewall Setup Guide > (http://www.shorewall.net/shorewall_setup_guide.htm). Or you may want to > get a good introductory addressing and routing text (I can''t recommend a > current one -- the one I learned from is out of date and out of print). > > -Tom------------------------------------------------------------------------- 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/