Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Dec 2014 03:17:38 +0800
From:      Julian Elischer <julian@freebsd.org>
To:        Jason Healy <jhealy@logn.net>
Cc:        freebsd-net@freebsd.org
Subject:   Re: IPv6 routes leaking between FIBs?
Message-ID:  <54A1A8D2.9080704@freebsd.org>
In-Reply-To: <ECBB89C5-05F4-464B-AE40-6EA446E516DD@logn.net>
References:  <C2295EFD-C052-438B-8524-974C17E1FBB6@logn.net> <54A0F4A7.5020502@freebsd.org> <ECBB89C5-05F4-464B-AE40-6EA446E516DD@logn.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12/30/14 1:59 AM, Jason Healy wrote:
> On Dec 29, 2014, at 1:28 AM, Julian Elischer <julian@freebsd.org> 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
>
>
>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54A1A8D2.9080704>