From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 03:32:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F38116A4B3 for ; Tue, 7 Oct 2003 03:32:19 -0700 (PDT) Received: from mayo.ewwww.com (mayo.ewwww.com [216.27.179.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFFDE43FE5 for ; Tue, 7 Oct 2003 03:32:18 -0700 (PDT) (envelope-from bharris@mayo.ewwww.com) Received: from localhost (localhost [127.0.0.1]) by mayo.ewwww.com (Postfix) with ESMTP id 5D4C510A9E; Tue, 7 Oct 2003 03:32:18 -0700 (PDT) Received: from mayo.ewwww.com ([127.0.0.1]) by localhost (mayo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04747-10; Tue, 7 Oct 2003 03:32:16 -0700 (PDT) Received: from mayo.ewwww.com (localhost [127.0.0.1]) by mayo.ewwww.com (Postfix) with ESMTP id 7908010A87; Tue, 7 Oct 2003 03:32:16 -0700 (PDT) Received: (from bharris@localhost) by mayo.ewwww.com (8.12.9+Sun/8.12.2/Submit) id h97AWFfx005099; Tue, 7 Oct 2003 03:32:15 -0700 (PDT) Date: Tue, 7 Oct 2003 03:32:15 -0700 From: Brendan Harris To: freebsd-hackers@freebsd.org Message-ID: <20031007103215.GA29943@stotch.com> References: <20031004235400.GA20943@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031004235400.GA20943@ussenterprise.ufp.org> User-Agent: Mutt/1.4.1i Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 10:32:19 -0000 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