Changing the NAT IP on demand?

[Brendan Harris]

On Sat, Oct 04, 2003 at 07:54:00PM -0400, Leo Bicknell wrote:
> 
> I'm considering options for a new project, and I think I've discovered
> what I think is the best idea, but I don't think current software
> supports the config.  I'd like to get some confirmation, and comments on
> if it would be hard to implement.
> 
> Consider:
> 
> 
> ISP #1-------\
>               \
>               FreeBSD Box----LAN
>               /
> ISP #2-------/
> 
> In this case the LAN would be 1918 space, the two ISP's would each
> provide a public IP for the FreeBSD box.
> 
> Now, NAT would be required.  What I want to do is write an external
> application to decide the performance of ISP #1 and ISP#2, and
> somehow tell NAT which outside address to use.
> 
> That, by itself, is not hard.  Here's the trick.  I want the switch
> to be seamless.  That is, if NAT is translating to ISP #1 and the
> application says switch to #2 the existing translations to #1 (until
> they go away naturally) should be kept, while new ones go to #2.
> 
> The only ways I know to change the outside address seem to tear down
> all existing connections.
> 
> Is it possible to make this work today?  Would it be hard to fix if 
> it doesn't work today?


Reading all of the replies and thinking about this a bit, really, I can see only one worthwhile solution to this: Run a routing protocol that can choose amongst static routes based on 'latency, hops and integrity' and just let it do it's own route-choosing on a per-connection basis.  Trying to lock "sessions" to a route is going to be a headache and won't provide you much more benefit than per-connection routing (unless a project you're doing requires the routes to be predictable for active sessions.)  If you _really_ want to write the interfacing application to achieve this, go for it.  But I would not do this if I were you.  Also, you're going to have a hell of a time achieving this when it comes to connection-less datagram protocols (e.g. UDP.)  So, I really recommend just letting a routing protocol handle this.

Also, someone mentioned a Linux solution to this.  I know there is an OpenBSD solution, using Packet Filter and NAT.  The two can interact with eachother seamlessly and I have done this before with OpenBSD.  You'll just need to choose a good routing protocol and learn the dirty details of Packet Filter and NAT (relatively the same as ipfilter and ipnat.)  You might want to look into that as a possible solution.


--Brendan