From owner-freebsd-questions@FreeBSD.ORG Tue Jun 21 16:29:40 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 0B744106566B for ; Tue, 21 Jun 2011 16:29:40 +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 BFAB48FC0C for ; Tue, 21 Jun 2011 16:29:39 +0000 (UTC) Received: from [192.168.0.51] (109.53-251-89.rdns.acropolistelecom.net [89.251.53.109]) (Authenticated sender: kha) by mail.dichotomia.fr (Postfix) with ESMTPSA id ED7143DD07C for ; Tue, 21 Jun 2011 18:26:52 +0200 (CEST) Message-ID: <4E00C720.5010701@dichotomia.fr> Date: Tue, 21 Jun 2011 18:30:24 +0200 From: Jerome Herman User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110607 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> <4DFFE6B9.2020107@dichotomia.fr> <4E00756B.5050805@my.gd> In-Reply-To: <4E00756B.5050805@my.gd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.dichotomia.fr); Tue, 21 Jun 2011 18:26:53 +0200 (CEST) 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 16:29:40 -0000 On 06/21/11 12:41, Damien Fleuriot wrote: > > On 6/21/11 2:32 AM, Jerome Herman wrote: > >> 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). >> > This does not depend on the route the client takes, but rather on the IP > the client tries to reach, wouldn't you agree ? Most of the problems I was afraid of were lifted when further explanations where given. But just for the records I would like to explain further what I meant, adding some examples. 1°) It is perfectly possible for a public IP to be routed differently depending on the ISP. Actually it is quite common when you have multiple provider to create "shortcuts" in the routing table. Let us say your main provider is ISP A who is officially routing your public IP, but you also have a privileged link with ISP B who will redirect any request made to your public IP to a private IP on your network (NAT or DMZ, your pick). All clients from ISP A will come to your public IP directly, all clients from ISP B will go through your private IP, but clients from ISP C ? Well it will depends on whether the route they elect goes to ISP A or ISP B first. 2°) Even if there are two distinct public addresses A & B , what happens when two nated computers behind an public address Z try to connect to the server at the same time ? reply-to disturbs the normal flow of answers, in case two connections are attempted from the same distant address at the same moment (second SYN received before first SYN/ACK is sent ) what is supposed to happen. I think each connection will receive a proper SYN/ACK from the right interface, but I cannot find anything to confirm/infirm this. 3°) Another thing that can happen, in case the interface selection is route dependent, is that the route can change between packet N and packet N+1. In this case using reply-to will very probably lead to a connection RST on the second interface while the first will go into timeout. So basically these were the problematics I was trying to point out in my previous mail. Hope I am clearer now Jerome Herman