All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Jaussaud <tatooin@kelkoo.com>
To: lartc@vger.kernel.org
Subject: Re: Re: [LARTC] multipath routing problem [Shorter version] - Help
Date: Fri, 25 Oct 2002 15:31:52 +0000	[thread overview]
Message-ID: <marc-lartc-103555995420076@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103555678715833@msgid-missing>

On Fri, 2002-10-25 at 16:55, Julian Anastasov wrote:
> 
> 	Hello,
Hi julian !

> 
> On 25 Oct 2002, Vincent Jaussaud wrote:
> 
> > > ssh tends to play with TOS fields (and rightly so). Routing is keyed to the
> > > *triple* (src, dst, tos), something that most people (including me) normally
> > > forget. However, in this particular case that may be the reason for your
> > > ssh's breaking.
> > >
> > Hmm... that's really interesting. Thanks for the pointer. I remember now
> > that I've read something regarding SSH & TOS field some days ago. If I'm
> > right, it use the Minimum Delay TOS value.
> >
> > Now, how am I suppose to deal with this TOS issue ? What TOS value
> > should do the trick ?
> 
> 	In theory, you should not reach multipath route for
> traffic that is already NAT-ed. May be you have to fix your
> routes. The TOS field plays in the input routing performed
> on forwarding and traffic between two public IP addresses can select
> different nexthop if the TOS is different or if the routing
> cache is somehow flushed (on route/address add/del, expiration).

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 ?  

> 
> > I'm using a 2.2 kernel with ipchains.
> >
> > > The reason for FTP breaking possibly has to do with packets for
> > > the control connection going out the one gateway and for the data going
> > > out the other... but this is speculation on my part.
> >
> > That sounds wise. However, routes are suppose to be cached using the src
> > IP field as well (If I'm not mistaken), so that every packets coming
> > from a particular IP are likely to take the same route than the others.
> > Am I wrong ?
> 
> 	Yes, TOS is a routing key just like SADDR and DADDR.
> By using multipath route between 2 IP addresses you agree that
> the packets can _safely_ choose any of the paths. When using
> two or more ISPs you simply can't do this if the ISPs have
> source spoofing disabled. In such cases only the traffic that
> is NAT-ed from your box has the right to use the multipath route.
> This is a key requirement for the patches you are using. Once
> the NAT connections are established they don't hit multipath
> route.
> 
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
suppose to ensure that every packets coming from a single connection use
the same path ?

Now, If I understand the whole topic, in order to fix my problem, I need
to:

	- NAT everything on the FW itself
	- or disable NAT on both gateways, and ensure that routing is done
properly


Am I right ? I'm becomming a bit lost, here :-\

Many Thanks for your time.
Vincent.

> > A BIG Thanks for your reply :-)
> > Cheers,
> > 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/

  parent reply	other threads:[~2002-10-25 15:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-25 14:38 Re: [LARTC] multipath routing problem [Shorter version] - Help Vincent Jaussaud
2002-10-25 14:55 ` Julian Anastasov
2002-10-25 15:31 ` Vincent Jaussaud [this message]
2002-10-25 16:12 ` Julian Anastasov
2002-10-25 18:15 ` Vincent Jaussaud
2002-10-25 18:17 ` Arthur van Leeuwen
2002-10-25 18:21 ` Arthur van Leeuwen
2002-10-25 18:44 ` Vincent Jaussaud
2002-10-25 18:45 ` Julian Anastasov
2002-10-25 19:13 ` Vincent Jaussaud
2002-10-25 19:28 ` Julian Anastasov
2002-10-28 14:29 ` Vincent Jaussaud
2002-10-28 22:21 ` Julian Anastasov
2002-10-29 16:32 ` Vincent Jaussaud
2002-10-29 22:31 ` Julian Anastasov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-103555995420076@msgid-missing \
    --to=tatooin@kelkoo.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.