From owner-freebsd-questions@FreeBSD.ORG Tue Jun 21 00:32:32 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D955C106566C for ; Tue, 21 Jun 2011 00:32:32 +0000 (UTC) (envelope-from jherman@dichotomia.fr) Received: from mail.dichotomia.fr (hydrogen.dichotomia.net [91.121.82.228]) by mx1.freebsd.org (Postfix) with ESMTP id 65DA88FC0C for ; Tue, 21 Jun 2011 00:32:32 +0000 (UTC) Received: from [192.168.1.18] (bgn92-1-81-57-223-72.fbx.proxad.net [81.57.223.72]) (Authenticated sender: kha@dichotomia.fr) by sslmail.dichotomia.fr (Postfix) with ESMTPSA id 07FFB3DD073 for ; Tue, 21 Jun 2011 02:29:45 +0200 (CEST) Message-ID: <4DFFE6B9.2020107@dichotomia.fr> Date: Tue, 21 Jun 2011 02:32:57 +0200 From: Jerome Herman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <201106202107.p5KL7PW0091851@x.it.okstate.edu> <4DFFC61B.2080201@radel.com> <27899_1308609017_4DFFC9F9_27899_767_1_D9B37353831173459FDAA836D3B43499BF89C588@WADPMBXV0.waddell.com> <4DFFD0A7.8010806@radel.com> In-Reply-To: <4DFFD0A7.8010806@radel.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (sslmail.dichotomia.fr); Tue, 21 Jun 2011 02:29:46 +0200 (CEST) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Two Networks on one System X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 00:32:32 -0000 On 21/06/2011 00:13, Jon Radel wrote: > > Can networks A and B talk to each other? I suspect not, otherwise > things would be just working even if all traffic went to the primary's > gateway, but I just wanted to check that there wasn't something else > bad happening. > > On the assumption that A and B are completely disconnected, then the > only solution for this problem that I know of is to do policy-based > routing using the source address or interface to make routing > decisions, rather than using solely the destination address. > > This is actually relatively trivial to do using PF. > > pass in on nic_a reply-to ($nic_a $gw_a) > pass in on nic_b reply-to ($nic_b $gw_b) From what I understand, there are two different ISP providing access to two different interfaces. In this case I am very concerned with all the bizarre things that a reply-to might trigger. What I mean is that nothing guarantees that a distant address will access the box from the same interface every time. I do not know what causes connection to be made on either nic_a or nic_b. Three things come to mind : - Multiple DNS resolution for an entry - Different routing rewriting depending on the ISP - An IP block being migrated from ISP A to ISP B with routes being updated while clients are connected So depending on the client route, packets from a given IP address can land on either interface. Actually two clients nated behind the same public address might end up on both interfaces at the same time. Even though your solution should work 99% of the time , it can lead to pretty strange behavior. I am not completely sure of how reply-to works, notably with keep state (and of course OpenBSD manuals on PF are down right now, at least from here). I remember attempting similar setups and having quite a lot of trouble with ICMP (especially RST for that matter). I guess that in order to cover all solutions there would be need to know what is exactly happening. The most important thing would be to know if both IP addresses on the server are public, or if there are private with DMZ/Port routing/NAT etc. If there is only a master DNS on the server, then I guess the worst thing that could happen would be strange timeouts and connection reset. But I there are data to be updated from the outside (DB, slave DNS, logs, mails etc.) things could turn out pretty badly. Actually I think the rules should be following not only the IP, but also the flags and the ports. Keep-state should take care of this once the connection is properly initiated, but during handshake I do not see how to guarantee proper resolution. Jerome Herman