From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 14:01:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A794E96A for ; Mon, 28 Apr 2014 14:01:10 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 83D1E10E2 for ; Mon, 28 Apr 2014 14:01:10 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s3SE14F3069040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2014 07:01:07 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <535E5F1B.7080302@freebsd.org> Date: Mon, 28 Apr 2014 22:00:59 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dominic Froud , freebsd-net@freebsd.org Subject: Re: Server with multiple public IP References: <535E1842.20905@netfence.it> <535E1C66.6090004@talk2dom.com> <535E231A.1050800@netfence.it> <535E293C.5050705@freebsd.org> <535E2A2F.3030505@freebsd.org> <535E362D.1050408@talk2dom.com> In-Reply-To: <535E362D.1050408@talk2dom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 14:01:10 -0000 On 4/28/14, 7:06 PM, Dominic Froud wrote: > > On 28/04/2014 11:15, Julian Elischer wrote: >> replying to myself.. >> >> On 4/28/14, 6:11 PM, Julian Elischer wrote: >>> On 4/28/14, 5:44 PM, Andrea Venturoli wrote: >>>> On 04/28/14 11:18, Andreas Nilsson wrote: >>>> >>>>> You could put all the services which are on 2.0.0.2 in a >>>>> separate fib and >>>>> there have another default-route. >>>> >>>> Thanks, but unfortunately I can't, since some services must be >>>> able to answer on both addresses. >>> >>> the answer is to use the ipfw setfib rule for incoming packets on >>> the second interface. >>> setfib 1 ip from any to any in recv em0 >>> In new freebsd kernels you can do this with ifconfig em0 fib 1 (I >>> think that's the syntax) without involving ipfw. >>> >>> then the session will inherit that fib. Outgoing packets from that >>> session will use fib 1 while other outgoing packets will use fib0. >> from the ifconfig man page. (FreeBSD 11 but I think it's in 10 too.) >> >> 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. >> >> this can be simulated using ipfw setfib should you not have it in >> the release you are running. >> > > "Outgoing packets from that session will use fib 1 while other > outgoing packets will use fib0." > > I haven't tried this but outgoing packets not associated with any > existing fib1 session (e.g. new TCP connections, UDP, etc.) could > also be attached to fib1 with a rule like this? > > setfib 1 ip from 2.0.0.0/29 to any out xmit vlan2 > > Keeping all the rules in ipfw is one advantage but then you have to > maintain 2 sets of routing tables - one for each fib. > > Doing source-routing with pf means two firewalls to manage but just > one routing table. You could argue that the routing table is > obscured by rules in pf though so doing "netstat -rnf inet" wouldn't > be authorititative. > > I'd like to do something like this: > > route add -srcnet 2.0.0.0/29 2.0.0.1 > > (kernel uses arp to translate 2.0.0.1 to an interface address like > vlan2) > ok so you have to make a decision on each session: "which link should I use for outgoing packets?" (You can't control incoming packets for sessions initiated remotely). answers are: (1) the one that the request came in on, so the session is symetrical. (2) one selected for some other reason. In this case the session may be asymetrical, and you need to pass out packets that appear to come from the other interface... Your ISP may hate you for this and block them as they are effectively "spoofed packets" from their perspective and it may break you service agreement. For outgoing sessions option 2 works fine and you can just use a single routing table to to this, or select which FIB to use with some "undisclosed" decision, but for incoming sessions you really would do best to make your outgoing packets go out the way the request came in, and this is what option 1 does.. by setting up two fibs, each with a separate default route, and just selecting the fib to use depending on the incoming interface. Some people (me) also sometimes use NAT as well so that the outgoing packet is NAT'd to the correct address as it exits (has to be an outgoing session though), but it can be from a computer behind you for which you are routing.. that is how you can put a whole intranet out on multiple ISPs. But you need a different NAT instance on each external interface. > Dom > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >