From owner-freebsd-net@FreeBSD.ORG Mon Dec 29 17:59:29 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 23C1EABC; Mon, 29 Dec 2014 17:59:29 +0000 (UTC) Received: from omicron.logn.net (omicron.logn.net [72.10.118.7]) by mx1.freebsd.org (Postfix) with ESMTP id 01A1764031; Mon, 29 Dec 2014 17:59:28 +0000 (UTC) Received: from [10.3.73.86] (unknown [10.3.73.86]) by omicron.logn.net (Postfix) with ESMTPSA id CCA294A0082; Mon, 29 Dec 2014 12:59:21 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: IPv6 routes leaking between FIBs? From: Jason Healy In-Reply-To: <54A0F4A7.5020502@freebsd.org> Date: Mon, 29 Dec 2014 12:59:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54A0F4A7.5020502@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1878.6) 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 17:59:29 -0000 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=92t. I=92m just coming over to FreeBSD and = while I=92m aware of jails, I thought of them more as service isolation = than for routing. I=92m searching around for a moment, and I=92m 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) - 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=92d need to throw the = 10g transit interface and the pfsync interface into the jail, and leave = the management interface on the host. I=92d probably need to run PF in = the jail as well? Or are we just using the jail to isolate the routing = tables, and I=92d still run PF on the host? I=92m happy to provide more details on the setup in case there=92s a = better way to architect this. I=92m a Debian/OpenBSD guy, so I=92m = sorry if I don=92t have all the terminology sorted out yet... I will still file a bug against the FIB code, as it sounds like that=92s = not working as intended/designed. Thanks, Jason