martin, you are truly the greatest network hacker around. i works like a charm, i removed the two rules that said "from <if-address>, use table 'main'", and used the one you provided. thank you so much! best regards, tomas bonnedahl On Thu, Mar 13, 2003 at 11:27:37AM +0100, Tomas Bonnedahl wrote: > On Wed, Mar 12, 2003 at 10:15:21PM -0600, Martin A. Brown wrote: > > Hi Tomas, > > hello again. > > > I hope you didn't sit there waiting for this answer! > > this time no. ;) > > > : things i like to clarify: > > : 1. rules 31000 and 31100 is just so that one address on a defined network can reach an > > : address on the internet, and that works perfect. > > > > Looks perfect. > > > > : 2. rules 32100-32400 is supposed to be so that the router can reach > > : defined networks, this does not work. > > > > This may be part of the "which comes first, the chicken or the egg" > > scenario you alluded to in your previous mail. I'm still trying to wrap > > my mind around the intertwined relationship between source address > > selection and route selection. I can't answer your implied question about > > why this doesn't work, nor can I answer your previous question about the > > ARP queries which never have a following ethernet frame with IP payload. > > exactly my thought too with the "chicken or egg". i have looked at the iproute2 > src code and also the kernel route.c code but since im not that good of a programmer > i couldnt make anything out of it. > > i may be stupid here, the arp quierys were sent when i was trying to ping the voIP > network, but it _could_ have come from legatime traffic from the lan (the works) so > the arp request didnt necessarily had to come in conjunction with my ping. im not sure > but when we have now looked further into this, it seems possible that it was not from > ping but from other traffic. > > > > Maybe one of the people more familiar with the kernel source code can help > > out here. > > yes. though im not sure anyone still reads this thread anymore, if anyone ever did. ;/ > > > > : some ascii art over the network: > > > > How about some modified ASCII art! Everybody loves ASCII.... > > > > 0/0 internet -----+ +-------------+ +---- defined networks ipsec > > \| fw |/ 10.47.17.0/24 > > +-------------+ 10.46.23.0/24 > > 192.168.2.1/24 10.100.0.0/16 > > | 192.168.75.0/24 > > | > > 192.168.2.2/24 > > +-------------+ > > 192.168.4.1/24 /| linux router|\ 192.168.1.1/24 > > / +-------------+ +--- LAN > > 192.168.4.2/24 / > > +------------+ > > | voip | > > +------------+ > > | > > +-- 172.16.1.0/24 > > > > This is what I'm able to gather from your routes and diagram, and you, > > sir, have a garden of networks. > > indeed true. you figured it out and made a much better outline than me. > > > I think what you want to do on "linux router" is to try the following > > (idiomatic) RPDB entry. > > > > # ip rule add iif lo table all # -- or table main in above case > > hm. i do not have the possibility to check this right now, but i will do it > as soon as possible. but i have to tell you, i really dont see what this "means" > or will change. just that everything that exits (and enters?) on the loopback if > will use table all? > > > I know it seems a very simple answer, to a complex question, but I hope it > > will work for you. > > well, so do i ;) > > > By the way, Tomas, did you know that you can have rule types in the RPDB, > > e.g., > > > > # ip rule add blackhole from 192.168.4.2 to 10.0.0.0/8 > > # ip rule add prohibit from 10.47.17.0/24 to 172.16.1.0/24 > > # ip rule add unreachable from 192.168.75.0/24 to 192.168.4.0/24 > > yes, i knew that. i choosed prohibit since the blackhole just drops them on the floor > and let the client time out. > > > OK, I know that tidbit doesn't help you in your current troubles, but I > > was hoping that the "iif lo" trick might help. > > ill check later today and ill mail back to you as soon as possible afterwards. > > thank you martin > > regards, > tomas > > _______________________________________________ > LARTC mailing list / LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >
