Re: [LARTC] policy routing problem

* Re: [LARTC] policy routing problem - solved
@ 2003-03-13 13:14 Tomas Bonnedahl
  2003-03-13 15:18 ` Martin A. Brown
  0 siblings, 1 reply; 2+ messages in thread
From: Tomas Bonnedahl @ 2003-03-13 13:14 UTC (permalink / raw)
  To: lartc

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@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 2+ messages in thread