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 routing tree ...
with the changes mentioned above, most things should
go back to normal, unless you bind certain services
to explicit IPs on the host.
you should also be able to reactivate the reverse path
filter with that (untested)
best,
Herbert
> > 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
> >
>
> --
>
> 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
Received on Mon Oct 2 15:20:55 2006