From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 19:17:50 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10F0BFCA for ; Mon, 29 Dec 2014 19:17:50 +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 BCBE61DCD for ; Mon, 29 Dec 2014 19:17:49 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-239-243.lns20.per1.internode.on.net [121.45.239.243]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sBTJHiAm067593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Dec 2014 11:17:46 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54A1A8D2.9080704@freebsd.org> Date: Tue, 30 Dec 2014 03:17:38 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jason Healy Subject: Re: IPv6 routes leaking between FIBs? References: <54A0F4A7.5020502@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Dec 2014 19:17:50 -0000 On 12/30/14 1:59 AM, Jason Healy wrote: > On Dec 29, 2014, at 1:28 AM, Julian Elischer wrote: > >> to some extent this is what it was written for.. teh fib code was written for Ironport/Cisco for separating the management port from the data ports onn their appliances, however the VNET code that came later is an even cleaner way of doing it and FIBs were only used by Ironport because VNET was not yet available. Have you tried vnet jails for interface isolation? > I freely admit that I haven’t. I’m just coming over to FreeBSD and while I’m aware of jails, I thought of them more as service isolation than for routing. > > I’m searching around for a moment, and I’m not 100% sure this is going to work for my use case. Can you confirm that jails would be the most appropriate way to solve my problem? These are the major requirements: > > - A router/firewall that will perform NAT from an internal RFC1918 space to public IPv4, as well as stateful firewalling of IPv6 packets passed to it. > > - 3 interfaces: > 1) Transit interface (10g, packets to/from PF are received/sent on this interface) > 2) PFsync (to connect to a second box for active-active PF) > 3) Management (LAN side only) the only hitch may be the pfsync stuff.. I have no idea about how virtualised that is and I never use pf..or pfsync. Basically you can assign a complatly separate network stack to teh management interface, (or the other ones) and run whatever the appliation is in the jail.. it's still possible to communicate with the jailed processes using shared files or fifos, but they have a completely separate network stack and are therefore completely unaware of the management interface. Each jail (if enabled with vnet option) has itsl own interfaces, routing tables, firewall(s) etc. > - Separate routing tables for the transit and management interfaces, so that the transit interface can have a default route that is distinct from that of the management network. > > It sounds to me that if I ran this as a jail, I’d need to throw the 10g transit interface and the pfsync interface into the jail, and leave the management interface on the host. I’d probably need to run PF in the jail as well? Or are we just using the jail to isolate the routing tables, and I’d still run PF on the host? > > I’m happy to provide more details on the setup in case there’s a better way to architect this. I’m a Debian/OpenBSD guy, so I’m sorry if I don’t have all the terminology sorted out yet... > > I will still file a bug against the FIB code, as it sounds like that’s not working as intended/designed. > > Thanks, > > Jason > > > >