From owner-freebsd-questions@FreeBSD.ORG Tue Jun 21 10:41:51 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 D605E1065674 for ; Tue, 21 Jun 2011 10:41:51 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62DD28FC19 for ; Tue, 21 Jun 2011 10:41:50 +0000 (UTC) Received: by bwz12 with SMTP id 12so3389195bwz.13 for ; Tue, 21 Jun 2011 03:41:50 -0700 (PDT) Received: by 10.204.171.1 with SMTP id f1mr640185bkz.194.1308652909964; Tue, 21 Jun 2011 03:41:49 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id ag6sm5234980bkc.18.2011.06.21.03.41.48 (version=SSLv3 cipher=OTHER); Tue, 21 Jun 2011 03:41:48 -0700 (PDT) Message-ID: <4E00756B.5050805@my.gd> Date: Tue, 21 Jun 2011 12:41:47 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; 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> <4DFFE6B9.2020107@dichotomia.fr> In-Reply-To: <4DFFE6B9.2020107@dichotomia.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 10:41:51 -0000 On 6/21/11 2:32 AM, Jerome Herman wrote: > On 21/06/2011 00:13, Jon Radel 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 ? Our PF boxes have 2 public IP addresses in 2 totally different networks, as well as public shared CARP IPs. Example: # PASS quick ICMP from trust IPs pass in quick on $ifvlan13 reply-to ($ifvlan13 $neo_vrrp_195) inet proto icmp from to icmp-type echoreq label "PASS in icmp_195" pass in quick on $ifvlan13 reply-to ($ifvlan13 $neo_vrrp_46) inet proto icmp from to icmp-type echoreq label "PASS in icmp_46" If you reach the box on it's 195.158.x.x IP (physical or carp), it'll reply through its router in the 195.158.x.x network If you reach the box on it's 46.182.x.x IP (physical or carp), it'll reply through its router in the 46.182.x.x network This is a production payment system so we'd know if there was trouble ;) > 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. Doesn't change much. > 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. > AFAIK during the TCP three-way handshake the initiator presents itself with a source IP and port and a destination IP and port, the source tracking does exactly what you're describing.