Changing the NAT IP on demand?

[Julian Elischer]

On Mon, 6 Oct 2003, Leo Bicknell wrote:

> In a message written on Sun, Oct 05, 2003 at 08:11:05PM -0600, Nick Rogness wrote:
> > 	In addition to keeping your NAT translations (as suggested by
> > 	Wes), you need to also keep routes for those entries as well, so
> > 	that preserved traffic remains to route out the right ISP even if
> > 	a switch occurs.
> 
> You're right, however I would go with a different mechanism, but one
> I've also never tried to do.  What you want is routing based on the
> source address of the packet, not the destination as per usual.  You
> want to be able to say "source a.a.a.a goes out link A".  I've never
> tried to do it on FreeBSD (it's easy on say Cisco's, with a bit of a
> performance hit on some platforms).  


this is very easy using the ipfw 'fwd' rule..

> 
> In a message written on Mon, Oct 06, 2003 at 05:28:57PM +0400, Yar Tikhiy wrote:
> > Just a random thought: If natd(8) were taught to change its default
> > alias address on the fly (it's just a single variable,) then the
> > desired effect would be achieved exactly.  That's because any session
> > already having its own entry in natd's aliasing table would use its
> > old alias address kept in the entry.  BTW, one could switch between
> > even more than 2 external connections in that manner.  And that's
> > just a step away from session-aware load-balancing with natd(8).
> 
> That's exactly what I was thinking, and more or less why I asked.
> 
> Note, I think this configuration would be useful in a lot of other
> applications as well.  Consider someone who can get, say, a 128k
> symmetric DSL line, and a 56k up 1M down satellite link.  If using
> this "trick" you could direct latency sensitive (ssh, telnet, ntp)
> traffic over the DSL line, and send bulk data (http, ftp) over the
> satellite link that could be quite useful.
> 
> I think I'm going to have to set up a lab box now and dig into this
> at a deeper level.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>