From owner-freebsd-net@FreeBSD.ORG Fri Sep 21 05:54:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3141106566B for ; Fri, 21 Sep 2012 05:54:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 991BB8FC08 for ; Fri, 21 Sep 2012 05:54:56 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-8.hsd1.ca.comcast.net [50.143.149.8]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q8L5soBW005582 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 22:54:50 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <505C0129.50202@freebsd.org> Date: Thu, 20 Sep 2012 22:54:49 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Michael MacLeod References: <505B2555.40704@doblej.net> <20120920180115.ede9a2b8.misho@elwix.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Michael Pounov 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: Fri, 21 Sep 2012 05:54:56 -0000 On 9/20/12 10:25 AM, 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." On Thu, Sep 20, 2012 at > 11:01 AM, Michael Pounov wrote: > hi, not a bad article.. a couple of things... firstly, though it's not relevent to THIS case, you can assign differnet fibs to different sockets on the same process, so theoretically a single sshd instance could do both tasks. The question is "how does it know which to use?" without extending sshd to add more config options for that, we have just a few possibilities.. Firstly, all sockets inherit their fib from that assigned to the process, but what if we didn't assign one to the process, but let the sockets take on the fib assigne to the packets of the incoming request? The packets in turn can get a fib from two sources: policy, via pf, or the ipfw setfib command, OR from the interface. as we can now assign a fib to an interface and packets coming in on that interface will take on the fib of the incoming interface. The only missing part of this is the code that lets teh process's fib float in the wind. I was considering setting this like: setfib -N sshd blah.... where -N would be expressed within the kernel as fib -1. In the socket code that would be inherited, and we would add code in the listen/accept code of the sockets so that when it discovers the socket is assigned fib -1, it switches it over to the fib of the incoming SYN packet (or whatever protocol). I've been meaning to a this ever since I added multifib support. It may require a small amount of code in every protocol (a line or two of C) This would allow us to make unmodified arbitrary networking servers work correctlty in multihomed systems. from man ifconfig: fib fib_number Specify interface FIB. A FIB fib_number is assigned to all frames or packets received on that interface. The FIB is not inherited, e.g. vlans or other sub-interfaces will use the default FIB (0) irrespective of the parent interface's FIB. The kernel needs to be tuned to support more than the default FIB using the ROUTETABLES kernel configuration option, or the net.fibs tunable. from man ifpw: setfib fibnum | tablearg The packet is tagged so as to use the FIB (routing table) fibnum in any subsequent forwarding decisions. Initially this is lim- ited to the values 0 through 15, see setfib(1). Processing con- tinues at the next rule. It is possible to use the tablearg key- word with a setfib. If tablearg value is not within compiled FIB range packet fib is set to 0. from man setsockopt SO_SETFIB can be used to over-ride the default FIB (routing table) for the given socket. The value must be from 0 to one less than the number returned from the sysctl net.fibs. see also: setfib(1), setfib(2), setsockopt(2)