Re: [Vserver] having a routing problem from guests
On Mon, Oct 02, 2006 at 11:46:32AM -0400, Chuck wrote: On Monday 02 October 2006 10:18, Herbert Poetzl wrote: oops... forgot.. ok so then i would add the statements below with proper ip for each of the 4 interfaces? yep best, Herbert add a masquerading/snat rule for each 'outgoing' packet on a specific interface, like this: iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I OUTPUT -o eth0 -j SNAT --to-source 64.113.32.2 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] having a routing problem from guests
On Tuesday 03 October 2006 11:42, Herbert Poetzl wrote: would that mix up things when guests on the same interface come into play? if on the host 32.2 interface a guest was 32.30 ?.. or would i have to add an iptables and iproute rule for each guest ip as well? On Mon, Oct 02, 2006 at 11:46:32AM -0400, Chuck wrote: On Monday 02 October 2006 10:18, Herbert Poetzl wrote: oops... forgot.. ok so then i would add the statements below with proper ip for each of the 4 interfaces? yep best, Herbert add a masquerading/snat rule for each 'outgoing' packet on a specific interface, like this: iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I OUTPUT -o eth0 -j SNAT --to-source 64.113.32.2 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] having a routing problem from guests
On Tue, Oct 03, 2006 at 11:51:36AM -0400, Chuck wrote: On Tuesday 03 October 2006 11:42, Herbert Poetzl wrote: would that mix up things when guests on the same interface come into play? if on the host 32.2 interface a guest was 32.30 ?.. or would i have to add an iptables and iproute rule for each guest ip as well? in a more complex setup it is generally advised to dedicate a separate table for each guest. if necessary, you can also use the mark feature of iptables to 'tag' traffic early and use that for advanced multipath routing (needs to be enabled) best, Herbert On Mon, Oct 02, 2006 at 11:46:32AM -0400, Chuck wrote: On Monday 02 October 2006 10:18, Herbert Poetzl wrote: oops... forgot.. ok so then i would add the statements below with proper ip for each of the 4 interfaces? yep best, Herbert add a masquerading/snat rule for each 'outgoing' packet on a specific interface, like this: iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I OUTPUT -o eth0 -j SNAT --to-source 64.113.32.2 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] having a routing problem from guests
On Tuesday 03 October 2006 12:06, Herbert Poetzl wrote: oh boy.. heh i may be getting into a real situation here.. each of the 3 public interfaces will have an average of 10 -20 guests on it by the time i am done and at least 8 of those guests will have upward of 10 ips in it with some 26 or more.. i used the 64ip patch (as much as possible.. legacy.h no longer has the variable to change). this means i have to set one up for each guest and each ip within... the ips were originally assigned years ago based on /24 not on subnets since the old machines had total access to all of a network. i have a feeling this is not gonna be fun unless i misunderstand something. (i am into creating a guest and telling it to 'fly' with little to no extra work :D ) On Tue, Oct 03, 2006 at 11:51:36AM -0400, Chuck wrote: On Tuesday 03 October 2006 11:42, Herbert Poetzl wrote: would that mix up things when guests on the same interface come into play? if on the host 32.2 interface a guest was 32.30 ?.. or would i have to add an iptables and iproute rule for each guest ip as well? in a more complex setup it is generally advised to dedicate a separate table for each guest. if necessary, you can also use the mark feature of iptables to 'tag' traffic early and use that for advanced multipath routing (needs to be enabled) best, Herbert On Mon, Oct 02, 2006 at 11:46:32AM -0400, Chuck wrote: On Monday 02 October 2006 10:18, Herbert Poetzl wrote: oops... forgot.. ok so then i would add the statements below with proper ip for each of the 4 interfaces? yep best, Herbert add a masquerading/snat rule for each 'outgoing' packet on a specific interface, like this: iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I OUTPUT -o eth0 -j SNAT --to-source 64.113.32.2 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] having a routing problem from guests
On Fri, Sep 29, 2006 at 11:23:11AM -0400, Chuck wrote: On Friday 29 September 2006 09:54, Herbert Poetzl wrote: On Thu, Sep 28, 2006 at 07:35:09PM -0400, Chuck wrote: my 32 net guests cannot contact outside 39 net machines on our same network. they can contact other 39 net guests on the same host. conversely, the external 39 net machine cannot contact any 32 net ip on the vserver host or any guest.. I assume you mean something like 10.32.0.x/24 and 10.39.0.y/24 here (well, at least it sounds like that is what you mean) 32net is a /23 and the other 3 networks are /24 the problem i had was when within a 32net guest if i ping a 39 net external host, it goes out our 39 net card to the external host gets answered and routed back into our host on 32net since the source ip header in the packet is 32 net and the system ignores it. yes, by default, the host is allowed to choose any network address which is assigned to an interface, the reverse path filter basically blocks packets which could not have originated from that interface, because it does not hold that ip setting below to 0 cures that. so, what you basically did, is to allow the packets to leave the interfaces with an ip from a different interface/routing too (which is harmless, but probably not what you actually wanted) actually it did not do what i wanted. we sniffed it this morning... the ping packets destined from the 32net guest for an external 39 net host still go out the 39 net card and get echoed back from the external host and the router sends them back to the 32net card since that was the source ip block, and by setting that to 0 it allowed 32net to accept the packet rather than reject it. what i want is no matter if it is an internal ip or not, for all traffic generated by a guest to go out its default port and come back into it directed by the router if a reply is required such as ping. yet at the same time it would be ideal for all guests to be able to route internally to each other as they do now. the way i want to see i suspect would send the packets external and the router would feed them back down the correct network. am i doing something extremely stupid by disabling this or is it secure enough not to worry? we are protected by tons of acls in various routers plus a very strict iptables on the host. the better approach would be to set up two routing tables, (given that there are two nics/routes on the host), and use source based routing to figure the proper interface we use iproute2 and have one table for each of the 4 networks on the machine.. it is extremely probable i dont have routes or rules set up right. it works like this but i just do not know if this internal routing the host kernel does is expected/desired/normal or not. this is a simplified version of our network setup... simplified=cut out 145 ip addresses from 34 net for saving space.. email runs on the host. eth0 differs in that it has an additional default gateway statement to handle unknown networks. # 32net intel e100 10/100 public switchport 3 vlan32 config_eth0=( 64.113.32.2 netmask 255.255.254.0 broadcast 64.113.33.255 ) routes_eth0=( 64.113.32.0/23 src 64.113.32.2 table 32net ) routes_eth0=( default via 64.113.32.1 table 32net ) try to add 'src 64.113.32.2' here ^^ #default gateway for sysem as a catch-all routes_eth0=( default via 64.113.32.1 ) better get rid of the 'default' only gives you wrong decisions rules_eth0=( from 64.113.32.0/23 table 32net ) #pvtnet tigon3 gbE private switch port 2 config_eth1=( 172.30.0.50 netmask 255.255.255.0 broadcast 172.30.0.255 ) routes_eth1=( 172.30.0.0/24 src 172.30.0.50 table pvtnet ) routes_eth1=( default via 172.30.0.1 table pvtnet ) rules_eth1=( from 172.30.0.0/24 table pvtnet ) # 34net tigon3 gbE public switchport 4 vlan34 config_eth2=( 64.113.34.2 netmask 255.255.255.0 broadcast 64.113.34.255 ) routes_eth2=( 64.113.34.0/24 src 64.113.34.2 table 34net ) routes_eth2=( default via 64.113.34.1 table 34net ) rules_eth2=( from 64.113.34.0/24 table 34net ) # 39net realtek rtl8169 gbE card public switchport 5 vlan39 config_eth3=( 64.113.39.3 netmask 255.255.255.0 broadcast 64.113.39.255 ) routes_eth3=( 64.113.39.0/24 src 64.113.39.3 table 39net ) routes_eth3=( default via 64.113.39.1 table 39net ) rules_eth3=( from 64.113.39.0/24 table 39net ) add a masquerading/snat rule for each 'outgoing' packet on a specific interface, like this: iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I OUTPUT -o eth0 -j SNAT --to-source 64.113.32.2 but if that 'works for you' then it is no big deal, as I said, it's usually off by default ... so then this behavior im forcing will not cause security issues? not necessarily, mostly confusion and sometimes strange delays when a router decides to flush a specific
Re: [Vserver] having a routing problem from guests
On Monday 02 October 2006 10:18, Herbert Poetzl wrote: cool thanks... ill make those changes and see how it works :) On Fri, Sep 29, 2006 at 11:23:11AM -0400, Chuck wrote: On Friday 29 September 2006 09:54, Herbert Poetzl wrote: On Thu, Sep 28, 2006 at 07:35:09PM -0400, Chuck wrote: my 32 net guests cannot contact outside 39 net machines on our same network. they can contact other 39 net guests on the same host. conversely, the external 39 net machine cannot contact any 32 net ip on the vserver host or any guest.. I assume you mean something like 10.32.0.x/24 and 10.39.0.y/24 here (well, at least it sounds like that is what you mean) 32net is a /23 and the other 3 networks are /24 the problem i had was when within a 32net guest if i ping a 39 net external host, it goes out our 39 net card to the external host gets answered and routed back into our host on 32net since the source ip header in the packet is 32 net and the system ignores it. yes, by default, the host is allowed to choose any network address which is assigned to an interface, the reverse path filter basically blocks packets which could not have originated from that interface, because it does not hold that ip setting below to 0 cures that. so, what you basically did, is to allow the packets to leave the interfaces with an ip from a different interface/routing too (which is harmless, but probably not what you actually wanted) actually it did not do what i wanted. we sniffed it this morning... the ping packets destined from the 32net guest for an external 39 net host still go out the 39 net card and get echoed back from the external host and the router sends them back to the 32net card since that was the source ip block, and by setting that to 0 it allowed 32net to accept the packet rather than reject it. what i want is no matter if it is an internal ip or not, for all traffic generated by a guest to go out its default port and come back into it directed by the router if a reply is required such as ping. yet at the same time it would be ideal for all guests to be able to route internally to each other as they do now. the way i want to see i suspect would send the packets external and the router would feed them back down the correct network. am i doing something extremely stupid by disabling this or is it secure enough not to worry? we are protected by tons of acls in various routers plus a very strict iptables on the host. the better approach would be to set up two routing tables, (given that there are two nics/routes on the host), and use source based routing to figure the proper interface we use iproute2 and have one table for each of the 4 networks on the machine.. it is extremely probable i dont have routes or rules set up right. it works like this but i just do not know if this internal routing the host kernel does is expected/desired/normal or not. this is a simplified version of our network setup... simplified=cut out 145 ip addresses from 34 net for saving space.. email runs on the host. eth0 differs in that it has an additional default gateway statement to handle unknown networks. # 32net intel e100 10/100 public switchport 3 vlan32 config_eth0=( 64.113.32.2 netmask 255.255.254.0 broadcast 64.113.33.255 ) routes_eth0=( 64.113.32.0/23 src 64.113.32.2 table 32net ) routes_eth0=( default via 64.113.32.1 table 32net ) try to add 'src 64.113.32.2' here ^^ #default gateway for sysem as a catch-all routes_eth0=( default via 64.113.32.1 ) better get rid of the 'default' only gives you wrong decisions rules_eth0=( from 64.113.32.0/23 table 32net ) #pvtnet tigon3 gbE private switch port 2 config_eth1=( 172.30.0.50 netmask 255.255.255.0 broadcast 172.30.0.255 ) routes_eth1=( 172.30.0.0/24 src 172.30.0.50 table pvtnet ) routes_eth1=( default via 172.30.0.1 table pvtnet ) rules_eth1=( from 172.30.0.0/24 table pvtnet ) # 34net tigon3 gbE public switchport 4 vlan34 config_eth2=( 64.113.34.2 netmask 255.255.255.0 broadcast 64.113.34.255 ) routes_eth2=( 64.113.34.0/24 src 64.113.34.2 table 34net ) routes_eth2=( default via 64.113.34.1 table 34net ) rules_eth2=( from 64.113.34.0/24 table 34net ) # 39net realtek rtl8169 gbE card public switchport 5 vlan39 config_eth3=( 64.113.39.3 netmask 255.255.255.0 broadcast 64.113.39.255 ) routes_eth3=( 64.113.39.0/24 src 64.113.39.3 table 39net ) routes_eth3=( default via 64.113.39.1 table 39net ) rules_eth3=( from 64.113.39.0/24 table 39net ) add a masquerading/snat rule for each 'outgoing' packet on a specific interface, like this: iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I OUTPUT -o eth0 -j SNAT --to-source 64.113.32.2 but if that 'works for you' then it is
Re: [Vserver] having a routing problem from guests
On Monday 02 October 2006 10:18, Herbert Poetzl wrote: oops... forgot.. ok so then i would add the statements below with proper ip for each of the 4 interfaces? add a masquerading/snat rule for each 'outgoing' packet on a specific interface, like this: iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I OUTPUT -o eth0 -j SNAT --to-source 64.113.32.2 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] having a routing problem from guests
On Thu, Sep 28, 2006 at 07:35:09PM -0400, Chuck wrote: my 32 net guests cannot contact outside 39 net machines on our same network. they can contact other 39 net guests on the same host. conversely, the external 39 net machine cannot contact any 32 net ip on the vserver host or any guest.. I assume you mean something like 10.32.0.x/24 and 10.39.0.y/24 here (well, at least it sounds like that is what you mean) the problem i had was when within a 32net guest if i ping a 39 net external host, it goes out our 39 net card to the external host gets answered and routed back into our host on 32net since the source ip header in the packet is 32 net and the system ignores it. yes, by default, the host is allowed to choose any network address which is assigned to an interface, the reverse path filter basically blocks packets which could not have originated from that interface, because it does not hold that ip setting below to 0 cures that. so, what you basically did, is to allow the packets to leave the interfaces with an ip from a different interface/routing too (which is harmless, but probably not what you actually wanted) am i doing something extremely stupid by disabling this or is it secure enough not to worry? we are protected by tons of acls in various routers plus a very strict iptables on the host. the better approach would be to set up two routing tables, (given that there are two nics/routes on the host), and use source based routing to figure the proper interface but if that 'works for you' then it is no big deal, as I said, it's usually off by default ... HTH, Herbert i found below in sysctl.conf was set to 1. if i set it to 0 as shown everything works properly.. # Enables source route verification. 0 disables net.ipv4.conf.default.rp_filter = 0 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] having a routing problem from guests
On Friday 29 September 2006 09:54, Herbert Poetzl wrote: On Thu, Sep 28, 2006 at 07:35:09PM -0400, Chuck wrote: my 32 net guests cannot contact outside 39 net machines on our same network. they can contact other 39 net guests on the same host. conversely, the external 39 net machine cannot contact any 32 net ip on the vserver host or any guest.. I assume you mean something like 10.32.0.x/24 and 10.39.0.y/24 here (well, at least it sounds like that is what you mean) 32net is a /23 and the other 3 networks are /24 the problem i had was when within a 32net guest if i ping a 39 net external host, it goes out our 39 net card to the external host gets answered and routed back into our host on 32net since the source ip header in the packet is 32 net and the system ignores it. yes, by default, the host is allowed to choose any network address which is assigned to an interface, the reverse path filter basically blocks packets which could not have originated from that interface, because it does not hold that ip setting below to 0 cures that. so, what you basically did, is to allow the packets to leave the interfaces with an ip from a different interface/routing too (which is harmless, but probably not what you actually wanted) actually it did not do what i wanted. we sniffed it this morning... the ping packets destined from the 32net guest for an external 39 net host still go out the 39 net card and get echoed back from the external host and the router sends them back to the 32net card since that was the source ip block, and by setting that to 0 it allowed 32net to accept the packet rather than reject it. what i want is no matter if it is an internal ip or not, for all traffic generated by a guest to go out its default port and come back into it directed by the router if a reply is required such as ping. yet at the same time it would be ideal for all guests to be able to route internally to each other as they do now. the way i want to see i suspect would send the packets external and the router would feed them back down the correct network. am i doing something extremely stupid by disabling this or is it secure enough not to worry? we are protected by tons of acls in various routers plus a very strict iptables on the host. the better approach would be to set up two routing tables, (given that there are two nics/routes on the host), and use source based routing to figure the proper interface we use iproute2 and have one table for each of the 4 networks on the machine.. it is extremely probable i dont have routes or rules set up right. it works like this but i just do not know if this internal routing the host kernel does is expected/desired/normal or not. this is a simplified version of our network setup... simplified=cut out 145 ip addresses from 34 net for saving space.. email runs on the host. eth0 differs in that it has an additional default gateway statement to handle unknown networks. # 32net intel e100 10/100 public switchport 3 vlan32 config_eth0=( 64.113.32.2 netmask 255.255.254.0 broadcast 64.113.33.255 ) routes_eth0=( 64.113.32.0/23 src 64.113.32.2 table 32net ) routes_eth0=( default via 64.113.32.1 table 32net ) #default gateway for sysem as a catch-all routes_eth0=( default via 64.113.32.1 ) rules_eth0=( from 64.113.32.0/23 table 32net ) #pvtnet tigon3 gbE private switch port 2 config_eth1=( 172.30.0.50 netmask 255.255.255.0 broadcast 172.30.0.255 ) routes_eth1=( 172.30.0.0/24 src 172.30.0.50 table pvtnet ) routes_eth1=( default via 172.30.0.1 table pvtnet ) rules_eth1=( from 172.30.0.0/24 table pvtnet ) # 34net tigon3 gbE public switchport 4 vlan34 config_eth2=( 64.113.34.2 netmask 255.255.255.0 broadcast 64.113.34.255 ) routes_eth2=( 64.113.34.0/24 src 64.113.34.2 table 34net ) routes_eth2=( default via 64.113.34.1 table 34net ) rules_eth2=( from 64.113.34.0/24 table 34net ) # 39net realtek rtl8169 gbE card public switchport 5 vlan39 config_eth3=( 64.113.39.3 netmask 255.255.255.0 broadcast 64.113.39.255 ) routes_eth3=( 64.113.39.0/24 src 64.113.39.3 table 39net ) routes_eth3=( default via 64.113.39.1 table 39net ) rules_eth3=( from 64.113.39.0/24 table 39net ) but if that 'works for you' then it is no big deal, as I said, it's usually off by default ... so then this behavior im forcing will not cause security issues? HTH, Herbert i found below in sysctl.conf was set to 1. if i set it to 0 as shown everything works properly.. # Enables source route verification. 0 disables net.ipv4.conf.default.rp_filter = 0 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book
Re: [Vserver] having a routing problem from guests
Taking this a step further I'm trying to do something similar and getting _strange_ results. Using totally fake IPs here is what I'm trying to set up. ( As typing this I see Chuck just posted to the thread with similar information. ) Host system with three NICs: eth0, eth1, eth2. Fedora Core 5 and all guests are FC5 using Daniel's excellent RPMs and was just updated this AM. eth0 is connected to a switch/router for one up-stream provider and has a block of 16 addresses designated for it: 123.45.67.192/28. eth1 is connected to different switch/router for a different upstream provider with a block of 16 addresses designated for it: 98.76.54.192/28. eth2 is connected to a switch which is the private in-house network for connection to the backup server, fileserver, and other non-public resources and can use any address in the 192.168.254.0/24 network. IT currently isn't configured or activated. I'll cross that bridge later. I've configured four guests so far. Three use the eth0 connection and one uses the eth1. I have created two files in /etc/sysconfig/network-scripts: route-eth0 route-eth1 They are using what I think is the current ( Redhat approved ) format. GATEWAY0=123.45.67.1 NETMASK0=255.255.255.240 ADDRESS0=123.45.67.192 and GATEWAY1=98.76.54.1 NETMASK1=255.255.255.240 ADDRESS1=98.76.54.192 I have assigned the IPs 123.45.67.193 and 98.76.54.193 to the two NICs for the host to use. ( Enforcement of the classless subnet isn't being enforced as the company the server is at has the full C Class for both IP ranges -- they're an ISP. ) ifcfg-eth0 contains: DEVICE=eth0 BOOTPROTO=static BROADCAST=66.193.36.255 HWADDR=00:00:00:00:00:00 # faked up IPADDR=123.45.67.193 NETMASK=255.255.255.0 NETWORK=123.45.67.0 ONBOOT=yes and ifcfg-eth1 contains: DEVICE=eth1 BOOTPROTO=static HWADDR=01:01:01:01:01:01 # faked up BROADCAST=98.76.54.255 IPADDR=98.76.54.193 NETMASK=255.255.255.240 NETWORK=98.76.54.192 ONBOOT=yes Lastly iptables is pretty open. The problem is that though I can ping from a different network to both of the host's to IPs and I can ping out from the three guests that use eth0 and I can ping the eth1 guest from a eth0 guest I can't ping from the eth1 guest to the outside world. The cursor just sits there blinking at me. #$%^* computers. :-) All the guests were created using the same set of commands with only the contexts, IPs, interface etc. different. So I'm hoping it is just something really stupid or overlooked on my part. Hope this is hijacking hte thread too much. Rod -- Herbert Poetzl wrote: On Thu, Sep 28, 2006 at 07:35:09PM -0400, Chuck wrote: my 32 net guests cannot contact outside 39 net machines on our same network. they can contact other 39 net guests on the same host. conversely, the external 39 net machine cannot contact any 32 net ip on the vserver host or any guest.. I assume you mean something like 10.32.0.x/24 and 10.39.0.y/24 here (well, at least it sounds like that is what you mean) the problem i had was when within a 32net guest if i ping a 39 net external host, it goes out our 39 net card to the external host gets answered and routed back into our host on 32net since the source ip header in the packet is 32 net and the system ignores it. yes, by default, the host is allowed to choose any network address which is assigned to an interface, the reverse path filter basically blocks packets which could not have originated from that interface, because it does not hold that ip setting below to 0 cures that. so, what you basically did, is to allow the packets to leave the interfaces with an ip from a different interface/routing too (which is harmless, but probably not what you actually wanted) am i doing something extremely stupid by disabling this or is it secure enough not to worry? we are protected by tons of acls in various routers plus a very strict iptables on the host. the better approach would be to set up two routing tables, (given that there are two nics/routes on the host), and use source based routing to figure the proper interface but if that 'works for you' then it is no big deal, as I said, it's usually off by default ... HTH, Herbert i found below in sysctl.conf was set to 1. if i set it to 0 as shown everything works properly.. # Enables source route verification. 0 disables net.ipv4.conf.default.rp_filter = 0 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list
Re: [Vserver] having a routing problem from guests
On Friday 29 September 2006 11:48, Roderick A. Anderson wrote: looks like you are doing what i did in the beginning.. using ifconfig.. wont work.. you must install iproute2 and use the rules and tables in order for it to work. my config is similar to what would be needed for iproute statements to make 3 or 4 or more nics work in one machine Taking this a step further I'm trying to do something similar and getting _strange_ results. Using totally fake IPs here is what I'm trying to set up. ( As typing this I see Chuck just posted to the thread with similar information. ) Host system with three NICs: eth0, eth1, eth2. Fedora Core 5 and all guests are FC5 using Daniel's excellent RPMs and was just updated this AM. eth0 is connected to a switch/router for one up-stream provider and has a block of 16 addresses designated for it: 123.45.67.192/28. eth1 is connected to different switch/router for a different upstream provider with a block of 16 addresses designated for it: 98.76.54.192/28. eth2 is connected to a switch which is the private in-house network for connection to the backup server, fileserver, and other non-public resources and can use any address in the 192.168.254.0/24 network. IT currently isn't configured or activated. I'll cross that bridge later. I've configured four guests so far. Three use the eth0 connection and one uses the eth1. I have created two files in /etc/sysconfig/network-scripts: route-eth0 route-eth1 They are using what I think is the current ( Redhat approved ) format. GATEWAY0=123.45.67.1 NETMASK0=255.255.255.240 ADDRESS0=123.45.67.192 and GATEWAY1=98.76.54.1 NETMASK1=255.255.255.240 ADDRESS1=98.76.54.192 I have assigned the IPs 123.45.67.193 and 98.76.54.193 to the two NICs for the host to use. ( Enforcement of the classless subnet isn't being enforced as the company the server is at has the full C Class for both IP ranges -- they're an ISP. ) ifcfg-eth0 contains: DEVICE=eth0 BOOTPROTO=static BROADCAST=66.193.36.255 HWADDR=00:00:00:00:00:00 # faked up IPADDR=123.45.67.193 NETMASK=255.255.255.0 NETWORK=123.45.67.0 ONBOOT=yes and ifcfg-eth1 contains: DEVICE=eth1 BOOTPROTO=static HWADDR=01:01:01:01:01:01 # faked up BROADCAST=98.76.54.255 IPADDR=98.76.54.193 NETMASK=255.255.255.240 NETWORK=98.76.54.192 ONBOOT=yes Lastly iptables is pretty open. The problem is that though I can ping from a different network to both of the host's to IPs and I can ping out from the three guests that use eth0 and I can ping the eth1 guest from a eth0 guest I can't ping from the eth1 guest to the outside world. The cursor just sits there blinking at me. #$%^* computers. :-) All the guests were created using the same set of commands with only the contexts, IPs, interface etc. different. So I'm hoping it is just something really stupid or overlooked on my part. Hope this is hijacking hte thread too much. Rod -- Herbert Poetzl wrote: On Thu, Sep 28, 2006 at 07:35:09PM -0400, Chuck wrote: my 32 net guests cannot contact outside 39 net machines on our same network. they can contact other 39 net guests on the same host. conversely, the external 39 net machine cannot contact any 32 net ip on the vserver host or any guest.. I assume you mean something like 10.32.0.x/24 and 10.39.0.y/24 here (well, at least it sounds like that is what you mean) the problem i had was when within a 32net guest if i ping a 39 net external host, it goes out our 39 net card to the external host gets answered and routed back into our host on 32net since the source ip header in the packet is 32 net and the system ignores it. yes, by default, the host is allowed to choose any network address which is assigned to an interface, the reverse path filter basically blocks packets which could not have originated from that interface, because it does not hold that ip setting below to 0 cures that. so, what you basically did, is to allow the packets to leave the interfaces with an ip from a different interface/routing too (which is harmless, but probably not what you actually wanted) am i doing something extremely stupid by disabling this or is it secure enough not to worry? we are protected by tons of acls in various routers plus a very strict iptables on the host. the better approach would be to set up two routing tables, (given that there are two nics/routes on the host), and use source based routing to figure the proper interface but if that 'works for you' then it is no big deal, as I said, it's usually off by default ... HTH, Herbert i found below in sysctl.conf was set to 1. if i set it to 0 as shown everything works properly.. # Enables source route verification. 0 disables net.ipv4.conf.default.rp_filter = 0 -- Chuck ...and the hordes of M$*ft users descended upon
Re: [Vserver] having a routing problem from guests
On Friday 29 September 2006 11:53, Chuck wrote: [snip] Lastly iptables is pretty open. The problem is that though I can ping from a different network to both of the host's to IPs and I can ping out from the three guests that use eth0 and I can ping the eth1 guest from a eth0 guest I can't ping from the eth1 guest to the outside world. The cursor just sits there blinking at me. #$%^* computers. :-) i had exactly the same symptoms when i first started this .. it only worked after switching to iproute2 and setting up tables and rules.. suddenly everything started working with the exception of my current problem of a /23 network not talking to a specific /24 network off the host... it is working now although i consider it a bandaid until i am assured this is how it is supposed to work internally. for redhat-style systems i do not know if iproute2 package replaces the init scripts and how the syntax works for setting routes and rules... it may have to be a separate script created with the proper ip route or ip rule commands.. All the guests were created using the same set of commands with only the contexts, IPs, interface etc. different. So I'm hoping it is just something really stupid or overlooked on my part. Hope this is hijacking hte thread too much. Rod -- Herbert Poetzl wrote: On Thu, Sep 28, 2006 at 07:35:09PM -0400, Chuck wrote: my 32 net guests cannot contact outside 39 net machines on our same network. they can contact other 39 net guests on the same host. conversely, the external 39 net machine cannot contact any 32 net ip on the vserver host or any guest.. I assume you mean something like 10.32.0.x/24 and 10.39.0.y/24 here (well, at least it sounds like that is what you mean) the problem i had was when within a 32net guest if i ping a 39 net external host, it goes out our 39 net card to the external host gets answered and routed back into our host on 32net since the source ip header in the packet is 32 net and the system ignores it. yes, by default, the host is allowed to choose any network address which is assigned to an interface, the reverse path filter basically blocks packets which could not have originated from that interface, because it does not hold that ip setting below to 0 cures that. so, what you basically did, is to allow the packets to leave the interfaces with an ip from a different interface/routing too (which is harmless, but probably not what you actually wanted) am i doing something extremely stupid by disabling this or is it secure enough not to worry? we are protected by tons of acls in various routers plus a very strict iptables on the host. the better approach would be to set up two routing tables, (given that there are two nics/routes on the host), and use source based routing to figure the proper interface but if that 'works for you' then it is no big deal, as I said, it's usually off by default ... HTH, Herbert i found below in sysctl.conf was set to 1. if i set it to 0 as shown everything works properly.. # Enables source route verification. 0 disables net.ipv4.conf.default.rp_filter = 0 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of
Re: [Vserver] having a routing problem from guests
Chuck wrote: On Friday 29 September 2006 11:53, Chuck wrote: [snip] Lastly iptables is pretty open. The problem is that though I can ping from a different network to both of the host's to IPs and I can ping out from the three guests that use eth0 and I can ping the eth1 guest from a eth0 guest I can't ping from the eth1 guest to the outside world. The cursor just sits there blinking at me. #$%^* computers. :-) i had exactly the same symptoms when i first started this .. it only worked after switching to iproute2 and setting up tables and rules.. suddenly everything started working with the exception of my current problem of a /23 network not talking to a specific /24 network off the host... it is working now although i consider it a bandaid until i am assured this is how it is supposed to work internally. for redhat-style systems i do not know if iproute2 package replaces the init scripts and how the syntax works for setting routes and rules... it may have to be a separate script created with the proper ip route or ip rule commands.. Yes, recent Redhat-ian systems use iproute2 and the sysv script (ifup-route) _seems_ to beat the route-eth? files into submission. I'm beginning to think I've done something odd to this guest or am completely confused as to the values I'm using. I'm going to try another later today of this evening. Thanks Chuck. Rod -- All the guests were created using the same set of commands with only the contexts, IPs, interface etc. different. So I'm hoping it is just something really stupid or overlooked on my part. Hope this is hijacking hte thread too much. Rod -- Herbert Poetzl wrote: On Thu, Sep 28, 2006 at 07:35:09PM -0400, Chuck wrote: my 32 net guests cannot contact outside 39 net machines on our same network. they can contact other 39 net guests on the same host. conversely, the external 39 net machine cannot contact any 32 net ip on the vserver host or any guest.. I assume you mean something like 10.32.0.x/24 and 10.39.0.y/24 here (well, at least it sounds like that is what you mean) the problem i had was when within a 32net guest if i ping a 39 net external host, it goes out our 39 net card to the external host gets answered and routed back into our host on 32net since the source ip header in the packet is 32 net and the system ignores it. yes, by default, the host is allowed to choose any network address which is assigned to an interface, the reverse path filter basically blocks packets which could not have originated from that interface, because it does not hold that ip setting below to 0 cures that. so, what you basically did, is to allow the packets to leave the interfaces with an ip from a different interface/routing too (which is harmless, but probably not what you actually wanted) am i doing something extremely stupid by disabling this or is it secure enough not to worry? we are protected by tons of acls in various routers plus a very strict iptables on the host. the better approach would be to set up two routing tables, (given that there are two nics/routes on the host), and use source based routing to figure the proper interface but if that 'works for you' then it is no big deal, as I said, it's usually off by default ... HTH, Herbert i found below in sysctl.conf was set to 1. if i set it to 0 as shown everything works properly.. # Enables source route verification. 0 disables net.ipv4.conf.default.rp_filter = 0 -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver -- Chuck ...and the hordes of M$*ft users descended upon me in their anger, and asked 'Why do you not get the viruses or the BlueScreensOfDeath or insecure system troubles and slowness or pay through the nose for an OS as *we* do?!!', and I answered...'I use Linux'. The Book of John, chapter 1, page 1, and end of book ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
