From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 19:17:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 343F916A468 for ; Thu, 12 Jul 2007 19:17:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outA.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2155C13C4B9 for ; Thu, 12 Jul 2007 19:17:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 12 Jul 2007 12:17:57 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id A7539125ADA; Thu, 12 Jul 2007 12:17:57 -0700 (PDT) Message-ID: <46967E76.4010702@elischer.org> Date: Thu, 12 Jul 2007 12:18:14 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Andrea Venturoli References: <4695FEF4.4030708@netfence.it> In-Reply-To: <4695FEF4.4030708@netfence.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Again two ADSL lines, routing problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2007 19:17:58 -0000 Andrea Venturoli wrote: > Hello. > I have a setup where a FreeBSD box is connected to two ADSL routers: > default gateway is set to the first and, in case of failure, is moved to > the other one. This works perfectly for outgoing connections: in the > event of the switch, I'll have to reconnect, but that's acceptable. > > The problem is in the incoming connections: if I get one on the "backup" > router, this will reach the server, which will however answer through > its "default" router. Thus the remote client will see packets coming > back from a different host and things won't work. > Just to be clear, the packets travel as follows (with source and dest IP > in brackets): > Client (x.x.x.x) -> Backup router (y.y.y.y) > Backup router (x.x.x.x) -> Server (z.z.z.z) > Server (z.z.z.z) -> Default router (x.x.x.x) > Default router (v.v.v.v) -> Client (x.x.x.x) > > So the client (x.x.x.x) connects to y.y.y.y (the backup ADSL public IP), > but gets answers from v.v.v.v (the master ADSL public IP). > > > AFAIK there is no solution to this, but I tought I'd ask before giving > my official opinion to my customer. > Perhaps there's some sort of hack we could use, that through > ipfw/natd/other diverting daemon/whatever delivers answers based on the > MAC address of the incoming connections (if the MAC address belongs to > the backup router, use that for answers)... does anyone know? > I have done this successfully as follows: firstly, you need to have NAT on Both interfaces, This ensures that from the point of view of the two ISPs each sees packets coming from the address they assigned you, even if they originate from machines in your local network. Then you need a way to allocate each session to one or the other of the links. The plain old routing table can do this. If you want to select which route to use according to SOURCE address (client) then you can use the 'fwd' command in ipfw, together with the skipto command to achieve this.. you need to make the decision as to which link you are going to use, and skipto the correct NAT rule and then the correct 'fwd' rule. (The packet will continue in the firewall after NAT so that it can then hit the FWD, but a FWD is termainal so you can't do it the other way around.. (hmmm, unless you do the fwd on incoming packets (on the inside interface)... does that work?) When one link dies you just switch he routing table as needed. (of course sessions pre-existing on the dead link will not survive but there isn't much you can do about that unles you tunnel to a third location.. > bye & Thanks > av. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"