Changing the NAT IP on demand?

[Wes Peters]

On Sunday 05 October 2003 01:02 am, Nick Rogness wrote:
> On Sat, 4 Oct 2003, 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?
>
> 	This can simply not work without resetting connections.  The
> 	socket pair on the "outside" would break as your outside traffic
> 	switches from one to the other (src/dst would change).  There is
> 	no fix, as this breaks basic IP principals.

That's not at all what Leo was asking.

Leo, you may be able to do this with ipfilter's ipnat.  Nat rules are 
traditionally processed with 'ipnat -CF', the -C clears the rules and 
the -F option clears the currently active NAT mappings.  You should 
experiment with rewriting the rules and instantiating them with -C 
only.  This should leave the existing stateful mappings to the formerly 
preferred interface while creating all new mappings on the newly 
preferred interface.

This might tend to confuse UDP-based services, which might see the next 
request as a different 'session', but I doubt those are much a problem 
across the internet.

Good luck.  If you run into bugs, I've always found Darren Reed to be 
helpful and interested in improving ipfilter/ipnat.  This might even be 
a feature that intriques him enough to pique his interest in making it 
a feature of ipnat.

-- 
         "Where am I, and what am I doing in this handbasket?"

Wes Peters                                                  Softweyr LLC
wes at softweyr.com                                    http://softweyr.com/