Date: Sun, 12 Aug 2001 02:11:43 +0200 From: "Karsten W. Rohrbach" <karsten@rohrbach.de> To: Tony Landells <ahl@austclear.com.au> Cc: freebsd-security@freebsd.org Subject: Re: distributed natd Message-ID: <20010812021143.A47419@mail.webmonster.de> In-Reply-To: <200108100115.LAA20997@tungsten.austclear.com.au>; from ahl@austclear.com.au on Fri, Aug 10, 2001 at 11:15:04AM %2B1000 References: <200108100115.LAA20997@tungsten.austclear.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable if memory serves me right, there was some loose lobby talk about implementing this in ipfilter at bsdcon last year. i don't remember who was involved, but anyway... /k Tony Landells(ahl@austclear.com.au)@2001.08.10 11:15:04 +0000: > Hi all! >=20 > I've been thinking about ways to improve the robustness of my firewall > and I came up with the following idea, so I thought I'd run it past > some other people for feedback. >=20 > The idea is to run two (or more) firewalls in parallel in such a way > that if one failed the other one would pick up the slack without users > noticing. >=20 > With our current firewall, we generally proxy connections, but for > some things (mostly SSH) we just let it through ipfw, using natd to > translate a "virtual" external address to the internal address of > the target host. >=20 > It occurred to me that if you could make a "distributed" natd, then > you could actually get everyone to use virtual addresses for everything, > and use dynamic routing to control which firewall handles the traffic. >=20 > As far as I can see, the requirements for doing this are: >=20 > a way to restrict the port numbers that natd will use so that > each firewall will have a unique range >=20 > a way for the natd processes on each firewall to tell each other > when they set up or delete a translation >=20 > a way for a starting natd process to obtain a state table from > the natd processes on the other firewall(s) >=20 > a way to tell each natd process what its "peers" are >=20 > Obviously, this wouldn't work terribly well with stateful packet > filtering... >=20 > I haven't even begun to look at the code for natd, but can anyone > see any fatal flaws in the concept? >=20 > Tony > --=20 > Tony Landells <ahl@austclear.com.au> > Senior Network Engineer Ph: +61 3 9677 9319 > Australian Clearing Services Pty Ltd Fax: +61 3 9677 9355 > Level 4, Rialto North Tower > 525 Collins Street > Melbourne VIC 3000 > Australia >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message --=20 > Get the all-new Microsoft[tm] IIS (Internet Intrusion Server[tm])! Out no= w! KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n= et/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- catch@spam.de GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B= F46 Please do not remove my address from To: and Cc: fields in mailing lists. 1= 0x --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7dcm/M0BPTilkv0YRAvo1AKC0sMQJCLFiK6yOunivqNmbFdZTwgCbBfZn RIr4+DId3oNBz7wrJWGXn6k= =StA0 -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010812021143.A47419>