Changing the NAT IP on demand?

[Nick Rogness]

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.

	A suggestion to make this kinda work would be to get a range that
	ISP#1 && ISP#2 would both allow you to route in/out.  Then you
	would have to write some app that routes your traffic out either
	ISP, keeping the same "outside" range.

	So you get a range (or single IP), call it X.X.X.X.  This is your
	external (non 1918) address. When packets leave your FreeBSD
	machine destined for the Internet, the source IP would be X.X.X.X.
	Since both ISP's allow source IP X.X.X.X out, it is only a matter
	of determining which ISP to send the traffic out to.  This would
	be done by modifying the routing table (or with fw forwarding of
	some sort).  The inverse is true with traffic inbound from the
	Internet to X.X.X.X.

	However, if you are going to go through this type of trouble, you
	might as well just route peer with the ISPs via BGP or whatnot.

Nick Rogness <nick at rogness.net>
-
  How many people here have telekenetic powers? Raise my hand.
  				-Emo Philips