From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 12:20:35 2012 Return-Path: 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 E8BFB106566C for ; Sun, 23 Sep 2012 12:20:35 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 936178FC17 for ; Sun, 23 Sep 2012 12:20:35 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id q8NCKSHQ094236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Sep 2012 14:20:34 +0200 (CEST) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id q8NCKSiK094235 for freebsd-net@freebsd.org; Sun, 23 Sep 2012 14:20:28 +0200 (CEST) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Sun, 23 Sep 2012 14:20:28 +0200 From: Paul Schenkeveld To: freebsd-net@freebsd.org Message-ID: <20120923122028.GA41844@psconsult.nl> References: <505B2555.40704@doblej.net> <20120920180115.ede9a2b8.misho@elwix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Multiroute question 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: Sun, 23 Sep 2012 12:20:36 -0000 On Thu, Sep 20, 2012 at 01:25:50PM -0400, Michael MacLeod wrote: > Actually, multiple routing tables is the correct solution. I documented it > here: > > http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using-multiple-routing-table/ > > >From the post: "... But route-to and reply-to do not trump the default > routing table for traffic that originates or terminates on the router > itself. They are useful only for traffic passing through the router. pf can > only make routing decisions when a packet passes through an interface. It > can try and set the reply-to interface to be the second WAN connection when > an inbound SSH connection is made, but neither the SSH daemon nor the > routing table on the host know or care about the routing preferences of pf." FWIW, I've many dual-homed machined running perfectly by combining pf for filtering and ipfw for policy-based routing. Basically, ipfw is configured roughly as follows (a.b.c.0/29 is the first WAN connection and d.e.f.0/29 the second): 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01001 allow carp from any to any 01002 allow pfsync from any to any 01100 allow ip from any to 10.0.0.0/8 01101 allow ip from any to 172.16.0.0/12 01102 allow ip from any to 192.168.0.0/16 01103 allow ip from any to 224.0.0.0/3 01110 allow ip from any to 01111 allow ip from any to ... 01200 fwd a.b.c.1 ip from a.b.c.0/29 to any 01201 fwd d.e.f.1 ip from d.e.f.0/29 to any 65535 allow ip from any to any Lines 1100 thru 1111 pass all traffic that should not go out over a WAN interface, they follow the normal routing table. I need the lines 011xx because I have multiple public IP address blocks on the inside and behind tunnels. Lines 1200 and 1201 forward packets to either WAN interface depending on the source address. I also have a default gateway set to my preferred WAN interface for connections originating from this host where the client does not explicitly select a source address. This works both for packets being routed and for packets originating from the dual homes host itself. I've been using this since FreeBSD 6 and never felt the need to switch to multiple routing tables because this fits the purpose and is quite clean IMO. It's also not necessary to run multiple server processes (like sshd, sendmail, httpd) for every routing domain. With kind regards, Paul Schenkeveld