Re: Re: [LARTC] multipath routing problem [Shorter version] - Help

[Vincent Jaussaud <tatooin@kelkoo.com>]

On Fri, 2002-10-25 at 18:12, Julian Anastasov wrote:
> 
> 	Hello,
> 
> On 25 Oct 2002, Vincent Jaussaud wrote:
> 
> > But traffic is NAT-ed after multipath routing occurs !
> > Eg, the box which do multipath routing do not NAT traffic; traffic get
> > NAT-ed when leaving the gateways:
> >
> > LAN --> FW w/ multipath-routing
> > 	   |		|
> > 	  Gateway1  Gateway2
> > 	   | (NAT)	| (NAT)
> > 	   |		|
> > 	-------------------- Remote Network
> >
> > Packets reach the Remote Network using one of the Gateway NAT-ed IP, so
> > that when packets come back they should use the proper return path. Am I
> > wrong ?
> 
> 	Now I see, then the TOS is a big problem for you. May
> be your problem will be solved if TOS is not a routing key but
> it does not sound as a thing that is easy to fix in kernel.
> 
> > Hmmm... Then this is where the problem is. So, if I understand
> > correctly, packets coming from a single TCP connections will use any of
> > the multipath route _if_ they are not NAT-ed ? Isn't the routing cache
> 
> 	Yes, traffic A->B with TOS=XXX will use one path, traffic
> A->B with TOS=YYY can use different path.
> 
Ok, I understand a lot of things now, thanks to you.
However, I don't get why, in the same SSH session, TOS may differ from
one packet to another. Using tcpdump, it seems that TOS value change
right after the authentication has been successfully made.

> > suppose to ensure that every packets coming from a single connection use
> > the same path ?
> 
> 	The routing does not cache connections but route resolutions keyed
> by saddr, daddr, tos, etc. Even there are no TCP/UDP ports (yet?).
> 
Ok. 

> > Now, If I understand the whole topic, in order to fix my problem, I need
> > to:
> >
> > 	- NAT everything on the FW itself
> 
> 	This is a solution
Yes, but unfortunately, and regarding my current networks architecture,
this will require massive changes in the firewall ACLs / routing rules. 
Currently, this is not an option.

> 
> > 	- or disable NAT on both gateways, and ensure that routing is done
> > properly
> 
> 	Not sure what you mean. But you can run multipath routes
> on the both gateways. Then the internal hosts can select any of
> the gateways as default (or to use alternative default gateways).
Each gateway only have one route to the remote network. So I don't see
where the multipath routing will send packets to, except maybe to the
other gateway. But this may become a big problem, in case all tunnels to
the remote networks are down; this will create a routing loop.


> Another solution is your apps not to change the TOS, it can be
> changed at the border gateways (if useful at all).
> 
Actually, and thanks to you, now I know where the problem is.
Considering that doing NAT on the firewall itself is not possible, and
that disabling  NAT on both gateways will quickly become a big headache,
because of the current networks setup, I think of adding another layout
of NAT on the final gateway.

Eg, something like:

LAN --> FW w/ multipath-routing
 	   |		|
 	  Gateway1  Gateway2
 	   | (NAT)	| (NAT)
 	   |		|
        Remote Gateway (other side)
	   	| (NAT)
		|
 	-------------------- Remote Network

This'll ensure that all packets arriving to the remove network comes
from the same IP address, whatever path they used.

What do you think of such setup ? Is it likely to work  ?

Thanks again.
Regards,
Vincent.

> > Am I right ? I'm becomming a bit lost, here :-\
> >
> > Many Thanks for your time.
> > Vincent.
> 
> Regards
> 
> --
> Julian Anastasov <ja@ssi.bg>
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
-- 
Vincent Jaussaud
Kelkoo.com Security Manager 
email: tatooin@kelkoo.com

"The UNIX philosophy is to design small tools that do one thing, and do
it well."

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/