From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 6 13:34:38 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3998106564A for ; Mon, 6 Jul 2009 13:34:38 +0000 (UTC) (envelope-from kim.attree@playsafesa.com) Received: from exchange.playsafesa.com (exchange.playsafesa.com [196.212.35.153]) by mx1.freebsd.org (Postfix) with ESMTP id D779C8FC15 for ; Mon, 6 Jul 2009 13:34:37 +0000 (UTC) (envelope-from kim.attree@playsafesa.com) Received: from server-02.playsafesa.com ([10.0.15.253]) by server-02.playsafesa.com ([10.0.15.253]) with mapi; Mon, 6 Jul 2009 15:35:16 +0200 From: Kim Attree To: Giuliano Gavazzi Date: Mon, 6 Jul 2009 15:35:15 +0200 Thread-Topic: Problem with source based policy routing Thread-Index: Acn+O5j5zTffeilyT0mCLkyADOky1QAAgsOQ Message-ID: <00265389C30B444288C246DF37651D0C37698F3933@server-02.playsafesa.com> References: <00265389C30B444288C246DF37651D0C37637A1893@server-02.playsafesa.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-ipfw@freebsd.org" Subject: RE: Problem with source based policy routing X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 13:34:39 -0000 > -----Original Message----- > From: Giuliano Gavazzi [mailto:dev+lists@humph.com] > Sent: 06 July 2009 03:13 PM > To: Kim Attree > Cc: freebsd-ipfw@freebsd.org > Subject: Re: Problem with source based policy routing >=20 >=20 > On M 6 Jul, 2009, at 10:36 , Kim Attree wrote: >=20 > > > > Hey Guys, > > > > > > > > I'm having a problem with source-based policy routing in IPFW, I'm > > trying to run a load-balanced SMTP System over two links. > > > > Primary link is re0, lets give it an ip of 192.168.1.1 > > Secondary link is re1, with an ip of 192.168.2.1 > > > > Default gateway for the box is 192.168.1.254 (so ALL outgoing > > traffic goes out of re0, unless hardcoded into the routing table for > > destinations instead) > > Default gateway for re1 is 192.168.2.254 > > > > I want re1 to be able to accept SMTP, but respond to the originating > > IP over the same link re1 (instead of the default gateway). > > With this in mind, I setup my NAT accordingly: > > > > > > port 8669 > > alias_address 192.168.2.1 > > same_ports yes > > use_sockets yes > > log_ipfw_denied yes > > redirect_port tcp 10.0.0.1:25 192.168.2.1:25 > > > > > > And the IPFW rules such: > > > > > > # NATD Statements > > add 00097 divert 8668 all from any to any via re0 > > add 00097 divert 8669 all from any to any via re1 > > >=20 > why NAT? Unless you also want to spread outgoing traffic from internal > hosts, presumably based on dest port or network, then NAT is of no use > (except the one via re0 that is presumably used for internal hosts). > Incoming packets don't need any rules as the gw 192.168.2.254 knows > how to reach your host, you only need to fwd (that is to route) your > outgoing packets according to the source. I have a similar setup (with > also 2 NATs because I do use both gateways also for natted hosts). I have one Internal Exchange server (don't laugh), and NAT handles the stat= ic mapping of IP/Port to that server. The original point here is to have tw= o mapped NAT port 25's to the same internal Mail server, hence the addition= of the NAT before and during the forward logic (obviously wrong though). =20 > The fwd rule would be very early, just after the loopback rules, > UNLESS you want to block outgoing traffic on some ports: >=20 > add 50 fwd 192.168.2.254 src-ip 192.168.2.1 not dst-ip 192.168.2.1/24 >=20 > That should do it. Because the incoming traffic traverses NAT, this wont work: 192.168.2.254 --> 192.168.2.1(NAT:25) --> 10.0.0.1:25 --> 192.168.2.1(NAT) = --> 192.168.2.254 --> World The forward ends firewall rule processing, meaning the traffic can not carr= y on outbound by my logic. > NOTE: if you also do NAT on that port (re1), then you need this also > after the corresponding nat rule. > But I urge you to distinguish between necessarily natted traffic (that > is traffic coming from internal hosts) and traffic coming from the > host itself, by using an alias on the same subnet (say 192.168.2.2) > for the natted traffic. This way you avoid natting traffic that does > not need it, and can easily distinguish between incoming traffic for > your host (192.168.2.1) and for natted hosts (192.168.2.2). >=20 >=20 > Giuliano Thanks for your assistance, any further help would be greatly appreciated != !! Kim