Date: Tue, 7 Oct 2003 03:32:15 -0700 From: Brendan Harris <bharris@stotch.com> To: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? Message-ID: <20031007103215.GA29943@stotch.com> In-Reply-To: <20031004235400.GA20943@ussenterprise.ufp.org> References: <20031004235400.GA20943@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031007103215.GA29943>